title: .NET two-way socket realtime communication protocol
body: <p>I need to maintain a connection between a server and multiple clients so that the clients can send commands, and the server trigger events. The server is basically a music-player, and the clients send commands like "Play()", "Pause()", "GetPlaylists()", etc. The server on it's side need to be able to tell the clients things like "SongEnded" or "PlayerPaused". And also, it needs to be possible to send some data to and forth (like current song, album image, playlists, etc.). I could of cause go ahead and create a socket myself and create my own protocol for handling all of the above scenarios, but chances are that someone has already done this before me, so what I really want is a framework made for real-time-communication between server and client for .NET. I've looked at xml-rpc for instance, but not sure how I should handle the "OnClientSend" with that. Also, if I'm not mistaken, xml-rpc is made to be REST-like. I've also looked at wcf, but since I have no experience with it I don't know where to start, and how to host the server in a simple console-app.</p>
  
  <p><strong>Important:</strong> The client needs to be able to not be .NET.<br>
  <strong>Important:</strong> This needs to be possible to connect to java (android).<br>
  <strong>Important:</strong> Primary platforms are windows (server and client), and Android (client).<br>
  <strong>Important:</strong> No streaming of audio is made. However, images needs to be sent.</p>
  
  <p>Any ideas for a solution would be appreciated. Also, if you got links to a good framework, or descriptions of how to use components already existing inside .NET I'd be really happy.</p>
  
  <p><strong>[Edit]</strong>
  The problem is that when sending data over sockets there is no guarantee (at all!) that the packages you sent will be read by the server at the same time. I might send 50, then 100, then 50 bytes again, but the server might read that as a 200byte chunk, or first 100 then 100 etc, which means I need to create a buffer, read in messages until I know for certain (this is the problem) that I've received a whole message (and nothing more).</p>