I'm facing a problem that gives me a quite hard time ...
People having trouble to execute a program that needs specific ports to be open, sadly they don't know if its a clientside problem caused by blocked ports, of it its simply a software problem.
So I thought about making a program that checks if the user can access the provided ports, after I made the WPF application, I was thinking about having an easier access to such functionality and tried to produce a Silverlight Version.
Questions:
a.) Is there even a way to check if the user can connect to specific ports that aren't in the range of 4502 - 4534 within a silverlight application that runs as plugin in the web browser ?
b.) Is there a way to do this, even without having access to the specific server to provide a policy file?
If you trying to do it from the in-browser application that its a no. Trusted silverlight application should be able to connect to any port without restrictions.
Related
i want to run 2 different BackgroundTasks - one for the communication with my arduino - and one for the communication with other devices by using a webservice. These tasks should be able to write and read from ONE database. But my problem is, that the Windows.Storage.ApplicationData does not provide the SharedLocalFolder. It is null, if I want to use it. Is there any other way where i can store my database that both BackgroundTask can connect to it?
Additionally I found now this path:(Windows.Storage.ApplicationData.Current.GetPublisherCacheFolder(...)). This look very interesting, but if i want to use it I cant write there. I think, because the resolved file path does not exist..
Any other ideas?
Sincerely,
App2App Communication via WebServer (Blinky WebServer):
You can refer Microsoft's IoT sample provided for Blinky Webserver which also depicts the concept of App2App Communication. But you need to read it thoroughly to modify and reuse it up-to your expectation.
Right now I have no experience about Windows IoT and database. Once I got my hands on it, I'll update.
Is it possible to make bittorrent client within silverlight, which will run in browser?
this would be unusual bittorrent client, he will download data from the server and will seed it. is it possible to do?
Is it possible to do within different, web tech, such as e.g. JavaFX?
Yes, completely possible. You can't receiving incoming connections, but that's no requirement for Bittorrent. The only thing that makes it difficult is that the peers you are connecting to need to serve a socketpolicy file on port 80 or 943, and almost none of them do. Without this policy, the Siverlight BT client will only work in the trusted 'Out of browser'-mode, which make it less usefull.
It's like a chicken-egg problem: as long as their is no large userbase for a Silverlight BT client, 'normal' nodes will not open port 943, and without that port, there never will be a large userbase for such an client.
Adobe solved this smartly by introducing Cirrus, their hosted rendezvous routing service which makes P2P possible from Flash without torrents.
No. You don't have access to the client's file system outside sandbox access.
http://betaforums.silverlight.net/forums/p/9351/29437.aspx
We currently have a silverlight application (kind of a game) and we need to add more functionality which requires more interaction with the server.
We currently do all interaction by HTTP requesting data from the server and then processing on the client - works well, until we have a lot of requests or larger data amounts being returned.
Sockets in Silverlight only work on port numbers between 4502 and 4534, is there a way of making this work on the internet? A way of allowing the user to simply accept and open up a port?
What is actually blocking the port range?
========
Just to add, is this somthing that is possible in Java (http://homepages.uel.ac.uk/2795l/pages/socketap.htm)
The only way to achieve this is via a proxy on the server or some sort of port forwarding taking place on the server.
This can not take place on the client side by itself.
What is actually blocking the port range is the SL runtime. It does this for security reasons.
In reality making use of sockets in an Internet based application would provide some hurdles most notably the need for the firewall to allow ports 4502-4534 to be open for Silverlight communication. This is one reason that the use of sockets is used more within an Intranet application where the need to open ports is non-existent (for the most part). Since Silverlight has defined these ports as the means of communication for their runtime it at least gives the admins some control over that range; versus allowing the runtime to operate on any given number of ports.
No direct way around it ( http://blogs.msdn.com/b/ncl/archive/2009/06/23/why-does-silverlight-have-a-restricted-port-range-for-sockets.aspx ).
I have an application which injects keystrokes into applications via SendKeys.
Unfortunately, the application will not work when I am running it via Remote Desktop
because of the well known issue that SendKeys doesn't work with Remote Desktop.
Has anyone solved this issue before, or have any good suggestions on how to resolve it?
SendKeys is not a good fit mainly due to:
It can only send keys to active/focused application, which is never guaranteed to work because the the active application can change between the time the keys are actually sent.
RDP and many other libraries (e.g., DirectX) block them mainly for security reasons.
Better alternatives:
Use SendMessage or SendInput for simple needs
Some good examples of how to use SendMessage can be found:
Send strings to another application by using Windows messages
SendMessage via pInvoke
How To Send Keystrokes To Extern Win Application
For more elaborate needs, it is recommended to use WCF
To get you started, read this Basic Tutorial that talks about Inter Process Communication
Sample code using SendMessage:
HWND hwndNotepad = FindWindow(_T("Notepad"), NULL);
HWND hwndEdit = FindWindowEx(hwndNotepad, NULL, _T("Edit"), NULL);
SendMessage(hwndEdit, WM_SETTEXT, NULL, (LPARAM)_T("hello"));
In my case I was successfully using WinAPI's SendInput with hardware scan codes. It seems like SendKeys maps chars to scan codes incorrectly.
You can workaround RDP issue by having desktop always logged in before use (or configured for auto-login # every boot).
And even with the auto-login, if you ever need remote desktop access to run automation, or manage system, etc., the preferred method is using VNC for remote access rather than RDP. Reason is VNC is cross platform and you won't run into this RDP issue. VNC works like a relay of your actual desktop (RDP console session 0 or the "head" of the machine), the disadvantage being one remote session at a time only (or you all share the same desktop + keyboard + mouse). VNC will work for virtual machines too. Use VNC instead of RDP or local (RDP) access from the (VMWare/Hyper-V/Xen) virtual machine manager software.
The only thing to watch out for with VNC still is that the desktop not be configured to auto-lock on idle or screensaver, that may also stop send keys and GUI automation from running, so be sure to disable that. Screensaver & monitor power save is ok, just no auto-lock & password protect.
NOTE: I'm not sure, but believe since VNC relays the desktop "as is", it is the same as executing locally from the app/system's point of view, so it should in theory also be able to fool the system/app that doesn't allow SendKeys via RDP. I've had no issues using this VNC method for AutoIt + SendKeys, whether I was actively connected via VNC, or disconnected (sendkeys/automation still continues to work after disconnect because on the actual desktop, it's still logged in, just that VNC not active).
In my case I was using sendkeys as part of test automation. It would not work from my build machine, where the build agent runs through remote desktop protocol. I'm not happy about it but I was able to skip that test as part of my automated builds.
Using Win32 calls to send window messages might work, if I have time I may try that someday.
Anyhow, here is the check to see if the current code is running in a remote desktop session:
System.Environment.GetEnvironmentVariable("SESSIONNAME").StartsWith("RDP-")
I am designing an application that requires me to access devices connected to the machine. We will have control of the machine, meaning control of the software and OS installed.
I know in the past one might suggest active-x controls, I was wondering is there a better solution? I have looked into Silverlight as an alternative, but not found much information supporting that design approach
Well, in theory, there's tcp support in Silverlight and so you could use that to talk to a local piece of software. In reality, tcp won't connect to the local machine unless you're in debug mode. So, that's a problem.
What people have been doing is creating a local WCF service and communicating with that. If you take this approach, don't forget to host up a cross-domain file as well.
I'd just add that if you can control what's on the client machine, WPF may be a much more straightforward answer :)
If you are speaking of the client's machine, Silverlight will not be of much help since it is sandboxed. In fact browsers and plugins are so locked down, that I think you should change your approach (maybe deploy your own client app, instead of using a browser/web app?)