I’ve started playing with sockets and have started on a small game for testing purposes. The server is asynchronous and it’s working good, but not great, so i’m looking for pointers from people who’ve gotten good results in their apps.
Scenario:
In the app i’m connecting to the server in Application_Launching/Application_Activated and disconnecting in Application_Closing/Application_Deactivated.
I noticed that in the “Tic-Tac-Toe Over Sockets Sample” on MSDN they’re closing the socket on the server every time when data has been sent to the app and connecting every time before data is sent from the app to the server.
Discussion:
Do people prefer to manage the connections in the app lifecycle events? It seems rather odd to open/close the sockets for each operation, like they do in the samples. Seems to nullify the advantages of using sockets in the 1st place.
Scenario:
Let’s say we’re implementing some sort of matchmaking method, which is relatively long-running. Let’s use 20 seconds as an example.
Discussion:
When the client asks for an opponent, would you prefer to loop the client list and sleep periodically until a suitable opponent has been found? Or would you recommend just adding the client to a pool of clients looking for opponents and loop through this periodically in a separate thread?
Bottom line is that if someone has successfully implemented a Windows Phone app/game using sockets i would love to get info on how you handled things like:
- Connection lifecycle
- Long-running operations on the server
- Clients quitting the app at “any time”, including when doing long-running operations on the server.
About the open/close:
MSDN sample in which it closes the socket after each operation is a neat practical method which most people might use. however there is no right way in socket programming. in fact there are a lot!
About threading:
Listenthen loop and sleep is a bad idea. you can’t cancel a blocking method.BeginSendorBeginListenthen threading is not needed.