In nonblocking socket mode. If i call send, and it returns less bytes than specified, a "short send". Then i dont want to have sent half a packet. Is there anyway to "peek" send? Iike PEEK for recv, ie, just check if its possible to send all the data, if not, dont send anything. Or if there is some way to get the number of bytes left in the internal send buffer. Im using nonblocking stream sockets. Anyone know? Thanks in advance.

What is your purpose in this? If you are trying to make sure that all the bytes arrive at the other end in one coherent blob, it won't work.

--Dave

no no, not at all. Im using a nonblocking network model for my game, no threads or anything. Therefor i cannot have send() block in the middle of the game loop. And i dont want to have to keep track of having sent 50bytes of "packet x" and then sending the rest of that packet the next tick of the game loop, or whenever it can be sent.

Then i just rather not send it untill i can send all of it. I realize ofcourse there is no getting around a short send if sending a 50mbyte file or something, but for small packets.

Dave's right, Peter. send() implies you're using TCP, sendto() implies UDP. TCP acts as a stream, so you're never, ever guaranteed packets will arrive in a block, and you're not given any sort of a promise as to how much any given call to send() will send. For sending lumped data either 0% or 100% and not having it get all mixed in with other data, you need UDP or some wrapper on top of TCP.

You might be worried about what to do with the leftover data you didn't succeed in sending. If you really can't let your program block, keep it in some sort of buffer until the next loop, then try again.

There may be a way to peek and see how big the outgoing buffer is, but it's almost certainly not the best way to go about whatever you're trying to do.

Partial sending at your level is counterproductive. The operating system's TCP stack will automatically send data in the most efficient blobs possible; this is a complicated thing and depends on the MTU of the network you're on (as well as any routed hops between you and the destination), the timing of packets, and so on. (c.f. the Nagle algorithm for a treatment of some of the concerns involved.)

The TCP stack knows better than you how to send efficiently-sized blocks of data, this is virtually guaranteed. The best way to use the stack is to send() blocks of as much coherent data as you can, and handle partial-sends and other conditions by retaining data that needs to be sent later.


Remember, there is no guaranteed correspondence between the buffers you place into send() (or get from recv() for that matter) and actual packets that are transmitted on the wire.

The Etwork library can give you these semantics over TCP, btw.