I'm from aWindows background of coding, so I don't know how this applies under Linux. But it should be similar.
When sending data you can dump as much as you like on the non-blocking socket (taking the maximum frame size into consideration to avoid unwanted splitting, but you have to do that with a blocking socket too). The only difference is that the snd function returns without waiting for the data to be sent. Thus the return value from the send is unreliable. You need to check your socket later if the data got sent or something went wrong. When receiving data it's pretty much the same. The only differecne is that recv doesn't wait for data. If there is none, it will return immediately. If there is (which means it's actually already received by the OS), your recv buffer will be filled. The only care must be taken with UDP packets, where reading on will always destroyit, if you got all the data or not. Note that this limitation also applies to blocking sockets. The 'bad' thing about creating sockets in HL plugins, is that most people do so in a situation where you shouldn't be using it. A good (or bad) example of this is the HLDS webserver. The idea might sound good, but dropping a webserver in a game is a BAD idea. But al long as the strain of the socket is low (only e few or even 1 client connected), you should be fine. Jeroen "ShadowLord" Bogers ----- Original Message ----- From: "botman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 28, 2003 00:28 Subject: Re: [hlcoders] building another tcp/udp port into hlds > > There should be no problems with opening a socket (udp or tcp) from a > > 3rd party plugin. The only thing to worry about is blocking for too long > > when reading from the socket (and potentially writing). Make sure the > > socket is non-blocking and do a zero time select() to poll the socket > > for data to read. > > Once you've set your socket up to non-blocking mode, like Alfred said, be > REAL careful about reading and writing data. > > For normal blocking socket operations, you can write a huge block of data > and the OS will suspend your process until it has completely written all of > the data. For non-blocking socket operations, you MUST check the return > values of the write function to see how much data was written. It might be > less than the size that you passed into the write function. This is your > indication that the OS can't shove any more data into the pipe right now and > you should try sending the rest of the data again in a little while (perhaps > during the next frame?). The point is that you can't just assume that all > of the data will be written to the socket when you tell it to. > > The same goes for reading. You might request 1000 bytes, but you might only > get back 200. You'll need to read again later to complete that read > operation. > > This all mostly applies to TCP. UDP is nastier in that the OS won't buffer > any data for you. If you don't read it all in one pass, it's gone forever. > I'm not sure what the result would be if you tried to write 1400 bytes to a > UDP packet and the OS was only able to write part of it. It probably won't > be a problem if you stick to small packets (less than the MTU size of 1400 > bytes or so), but it could become a large problem if your packet size is > fairly big. > > Jeffrey "botman" Broome > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
