• 12
• 27
• 9
• 9
• 20

# [.net] Visual Basic .net Asynchronous Sockets Questions

This topic is 4137 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm trying to build an asynchronous socket class but I'm running in to a lot of problems, for now the application is just being able to send/receive an array of bytes to keep it simple. 1.) For games, are seperate sockets used for sending and receiving? If not, would the situation arise where someone with a high ping could send to the server the same time the server was sending out so neither would be asynchronously receiving at that time and you would haveto continue resending, possibly with the same result? 2.) What is the basic walkthrough of a send and receive socket. So far I have: Server) Bind, Listen, BeginAccept, EndAccept, BeginReceive, EndReceive, and then if it's two way just having BeginSend and EndSend with another BeginReceive after the EndSend. I'm calling Shutdown(Both) before BeginDisconnect(true for the reuse param) then EndDisconnect, but I get errors when trying to connect again, am I supposed to just make a new socket since there is no opposite to Shutdown? Client) BeginConnect, EndConnect replaces the first 4 on Server and I'm having the same problems with EndDisconnect. 3.) Do you have to put error checking everywhere to make sure you don't try to do things if the socket you were connected to disconnects from you? Is there anyway to find out without an error and without polling? 4.) Is it actually neccessary to check EndSend for bytes if you are using TCP? - Thanks in advance if you can answer any of these. I realize microsoft has a tutorial for asynchronous sockets but it's just a call and response system where each system shuts down after receiving and sending once so it doesn't really help me that much, and I couldn't find anything else in a .net language.

##### Share on other sites
For a game, a good network scheme (if you just want to use straight sockets) would be send all packets as udp and send them all duplicated with timestamps. This will ensure more integrity. If you don't recieve a group of them then use a pull method to get the information from the client to the server. Do not push data from the game client to the server. Or, just ignore that group of packets entirely, and don't send a confirmation. They will still be marked as unhandled, and then will get pulled again. Just mark them as handled and be done with it.

Also, the most robust way to handle a tcp/ip connection in a game is to recieve all packets as messages copied to a file in a directory and then have some other distributed process that chews up and processes the messages. Of course you should use an in memory equivilant of this kind of operation instead... I am just trying to point out the basic concept.

Yes, more than one socket can be a good idea. Ftp uses this idea. Check out pasv mode ftp for more information.

Honestly, your problems in a game library will be bigger in the area of protocol than they will be in the sending of the actual data back and forth. A good concise protocol is essential, to keep latency minimized. A pull model is also essential to keep your servers from getting overloaded.

##### Share on other sites
Quote:
 1.) For games, are seperate sockets used for sending and receiving? If not, would the situation arise where someone with a high ping could send to the server the same time the server was sending out so neither would be asynchronously receiving at that time and you would haveto continue resending, possibly with the same result?

Generally you'd only have one socket per client (TCP) or one socket for everyone (UDP). You don't need two sockets for most purposes. And no, you can't get 'data locks' like that; the OS will buffer the incoming data so the next time you read (synch or asynch, it doesn't matter) from the socket the data will be there.

Quote:
 Server) Bind, Listen, BeginAccept, EndAccept, BeginReceive, EndReceive, and then if it's two way just having BeginSend and EndSend with another BeginReceive after the EndSend.

If you're using TCP, the Accept call will give you a new socket on which you should do all your data I/O. The server socket should remain listening and you should call Accept again to allow your server to have multiple clients. Here's the Accept callback from my network library (obligatory pimpage):
 void AcceptCallback(IAsyncResult ar) {  try{   Socket server = (Socket) ar.AsyncState;   Socket cs = server.EndAccept(ar);   // Start the thing listening again   server.BeginAccept(new AsyncCallback(AcceptCallback), server);   // Allow the new client to be rejected by the application   ClientInfo c = new ClientInfo(cs, null, null, ClientDirection.Both);				c.server = this;   if(Connect != null){    if(!Connect(this, c)){     // Rejected     cs.Close();     return;    }   }   clients.Add(c);  } catch(ObjectDisposedException) {}  catch(SocketException) {} }

Yes, once you've disconnected a socket you need to create a new one to reconnect.

Quote:
 3.) Do you have to put error checking everywhere to make sure you don't try to do things if the socket you were connected to disconnects from you?

Yes; the TCP interface typically only tells you that a socket is gone when a send or receive call is attempted, this isn't even a .Net thing. So yes, any Send or Receive call may throw a SocketException. As far as I know there is no reliable way to get the information without trying, though the Socket.Connected property will sometimes tell you.

Quote:
 4.) Is it actually neccessary to check EndSend for bytes if you are using TCP?

It is good practice, though if you're only sending small amounts of data you should never get a partial send.

Re BradSnobar's comments: yes, you absolutely must implement a messaging protocol if you are using TCP (or use someone else's). TCP does not guarantee that one Send() matches one Receive(), and it very commonly doesn't.