I am creating a screensharing application that would work in a similar manner like Google Hangout Screen Shares, and I'd like to know how the Google Talk plugin (used for Screen Shares) spawns child processes and uses a dynamic port range.
I am creating a background running application that user will have to install, and which talks with browser like how they describe here, http://www.codeproject.com/Articles/36517/Communicating-from-the-Browser-to-a-Desktop-Applic
But when I look at googleTalkPlugin, which is responsible for google hangout screen sharing, I saw that there are a lot of processes running, and whenever I open a new browser, a new talk plugin for that browser starts, as child service.
Here are some snapshots
and when I noticed the port used by googleTalkPlugin, I came to know its dynamic! If you saw the above link, the Browser Desktop communication is on static port.
I am very interested in knowing, how do I use dynamic port numbers? Also, should I create child process for every browser?
Or something better?
The reason there is a separate child process for each browser is that the Google Talk application is implemented as a browser plugin. Each browser has a Google Talk plugin installed and doesn't know about the other browsers, their plugins or their subprocesses. Each browser will launch the plugins that it has installed and, as Eduard mentioned in the comments, some plugins are started in a separate process. This isn't behavior that is special about Google Talk, it is behavior you will see with most plugins. If you implement your application as a browser plugin you will have the same behavior. If you don't want your application to run as a subprocess of a browser then you will need to write it as a standalone application, not a browser plugin.
If you want to learn more about spawning subprocesses read up on fork(). There are lots of other good resources around the internet on subprocesses.
Your other question is around dynamic port numbers. The easiest way to do this is to bind to port 0 and you will be assigned a random open port by the operating system. You can then use getsockname() to find out what port you ended up with. If you are working with a client/server situation you can have the client do this and then just tell the server which port it is using.
Related
I am finding some conflicting articles, some are old, about CN1 not having Sockets but I see the library com.codename1.io.Socket. I have seen some articles saying it works on Android as well but not iOS. I need the capability to listen on a socket on iOS and was hoping to use an internal library. The shannah/CN1Sockets project doesn't appear to support listening.
From 2014, https://www.codenameone.com/blog/sockets-multiline-trees.html , and lists non iOS support. Any update on this?
Codova/Phonegap does have a few libraries and someone implements Chrome's TCP/UDP API for it as well.
Server sockets are very problematic across platforms as the iOS implementation is radically different from the Android implementation and a bit challenging to implement using the listen paradigm.
It's probably possible to implement server sockets on iOS but because there wasn't much demand and this required some work we chose not to do it. It's also not very useful ans phones move around/change networks. You won't get a stable IP to work against anyway. A better way would be to initiate communication from the client and then communicate back. Notice you won't be able to use a server socket in a background process in iOS anyway as the process will be killed when sent to background!
The only Cordova implementation I found is this: https://github.com/MobileChromeApps/cordova-plugin-chrome-apps-sockets-tcpServer
You can probably use that with native interfaces or just use it as a baseline for a pull request to implement server sockets on iOS but again it's very unlikely that what you are trying to do with server sockets won't work due to iOS limitations.
I am currently building a chat server (meebo style).
The architecture is something like this.
Bitlbee over libpurple is on host B. Its a trivial server on data center.
User communicates with bitlbee via web server (just like meebo) on Host A. The backend of this web server maintains chat session. It just translates the user commands to proper bitlbee comamnd and sends back to host A.
The most important part here is that host A will be deployed in embedded Linux.
I have 2 questions.
To keep the chat session persistent I am thinking of using node.js. As its much more easier to create a real time application with persistent connection. But I doubt if its supported in such platform.
If I use C instead of node.js (I am not using any web server) I can talk to the irc server at host A by libirc. But how do I implement all the web server features in C (like session, url/cookie/post data parsing etc) ?
Also if you think my approach is wrong or there is a better approach please tell me how can I improve this architecture?
Note: This is NOT a high volume chat server.
If building V8/Node.js is prohibitive on the embedded platform, the next best thing would be to take the event loop and platform layer (libuv) and HTTP parser (http-parser) of Node, both written in C and use those as a starting point. These are the same libraries used to build Node.js so they are battle tested and will give you the performance characteristics you seek.
Ryan Dahl, author of Node.js, demonstrates exactly how to use libuv and http-parser to build an asynchronous web server in C.
Put a ZNC server between Bitlbee and the web-based IRC client. Bitlbee will think that the user has never logged out and ZNC can maintain a backlog of messages until the user connects again with the web client.
I would try to go with node.js if that is your choice, also what embedded system is it? As knowing that would help more. Also, another plus for node.js is that it does have session handling built it, but if you wanted to do it in C try and see if you can get a sqlite wrapper running on the embedded device to store the session information.
But, if possible stick to something with less work on embedded devices, feels bad to reinvent a lot of stuff or have to fiddle with compile issues for your device.
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.
If there was a process on the user's desktop, would Silverlight be able to communicate with it? Is there a way to send messages from SL to a process that runs in the background and vice versa?
P.S. I am particularly interested in non-OOB SL.
Running OOB, with Elevated Trust would allow to open a socket connection to arbitrary destinations, including a local process hosting a listen socket. Otherwise I see no way how to do it.
No. Silverlight will not allow you to deal with anything outside the web browser in non-OOB.
Silverlight -> JavaScript -> ActiveX
http://forums.silverlight.net/forums/p/17053/206880.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-")