What would be a decent method of dealing with the fact that send and recv do not always send the entire packet/buffer If I have a struct to send across and the whole thing doesn''t get sent, must I re-construct the multiple parts on the recieving side, and how will the recieving side know how much of the message is still to arrive? my TCP socket sometimes splits a 2 byte packet...is this really necessary?

Yep. When you create a TCP socket you specify SOCK_STREAM, right? It doesn't deal with "packets" so much as it does a stream of data.

A word to the wise : using TCP will only bring you heartache in the long run. In a "serious" application, the giant wall you will inevitably hit is that (wait for it...) :

You cannot control if or when a TCP socket will be arbitrarily shut down by the socket layer.

Ergo, a large enough net burp, or other stuttery situation and people get disconnected in ways you cannot control. SPX (the stream equivalent of SPX) is even worse.

My advice - write your own small "reliable" layer on top of UDP. Do ack/nak resends and timeouts. 99% of your packets -do not- need to use this anyway and can go with simple fire-and-forget UDP.

Also - sending structs is a no-no. Break them down into their component parts and package them individually into a packet. Why? Just trust me.

[edited by - daveb on February 20, 2003 12:19:17 AM]

or you can use overlapped sockets and/or completion ports, which always send the buffer completely when the operation finishes.

quote:

---

Original post by AntiVeggieBoy
If I have a struct to send across and the whole thing doesn''t get sent, must I re-construct the multiple parts on the recieving side...

---

you have to do this regardless of whether the send operation completes in one go or not. due to the streaming nature of tcp, even if you sent 100 bytes with one send call you might receive only 50 bytes if you do a recv on the other end, and get the other 50 bytes later.

quote:

---

... and how will the recieving side know how much of the message is still to arrive?

---

you can send message length right before the message so the receiving end knows how much data to expect.

also note that tcp can collapse multiple sends into one receive, that is, if you send 100 bytes and then another 100 bytes you can receive 200 bytes (or 150 bytes) in one recv call.

Overlapped sockets; completion ports?
I''ve searched and read a thousand winsock tuts, why have I never heard of those?

That previous post bummed me out more than anyone could imagine.
I have a gorgeous client/server class that works beautifully
other than those occasional split messages.
I am using length prefixing, but just once even the length didn''t get through, so then everything goes down the toilet.

quote:

---

Original post by AntiVeggieBoy
Overlapped sockets; completion ports?
I''ve searched and read a thousand winsock tuts, why have I never heard of those?

---

overlapped socket i/o links
iocp links

quote:

---

That previous post bummed me out more than anyone could imagine.
I have a gorgeous client/server class that works beautifully
other than those occasional split messages.
I am using length prefixing, but just once even the length didn''t get through, so then everything goes down the toilet.

---

it''s better to fix your code now than wait until it breaks, and it will break eventually. if you''ve only been testing your code on localhost, going on lan or dial-up will likely break it.

Hmmm, NT4.0 or higher only.
Is that acceptable these days?

overlapped sockets work for 9x.

> I have a gorgeous client/server class
> that works beautifully other than those
> occasional split messages.

Try the following:

setsockopt( ... TCP_NODELAY ... );

Keeping your messages below 1.4Kb also helps.

-cb

quote:

---

using TCP will only bring you heartache in the long run. In a "serious" application, the giant wall you will inevitably hit

---

whoa... don''t scare the guy like that. There are plenty of serious applications using TCP. I''m using one right now

quote:

---

Also - sending structs is a no-no. Break them down into their component parts and package them individually into a packet. Why?

---

Why?


----------
Dauntless for President!
zppz.homeip.net <- game dev stuff