Crazy Send and Recv behaviour

[ifmusic]

i have this sort of server - client (which is described as servents in
the gnutella specification, and it's what i'm trying to do..)
And this is what happens:
SOMETIMES, when computer A sends through a socket 37bytes, Computer B
recieves 37bytes, and prints certain info about it.
Now, other more irritating TIMES, computer A has to send two Packet,
one first, then another, both 37bytes long , the Send function on
computer A Tells me, Hey! i sent 37bytes, and then, the same, So i Say,
OK, computer A sent 2 37b messages. Now the funny part is.. Computer B
says Hey! i recieve something.. It's 74bytes (37 * 2) long!!! So i
kinda have a problem. Again, This happens sometimes!. And IN FACT,
after checking with ethereal (sniffer) there are Exactly 74bytes
travelling through the net!. So What should i think.. computer A said i
have to send 37b but i wont do it now, now i have to send another 37b
msg? Ok, i'll send both within the same Frame Eth, TCPIP packet!; just
to bug computer B, Je JE!.
I know that sometimes the OS may decide whether to split packets
because thet're long or whatever (i read some of the Beej's tutorials
on sockets) but i dont think this is the case.

this is crazy for me. Cant handle it.
Please Help!.

ps: i'll try to give you some of the code.

 

[Gordon Burditt]

i have this sort of server - client (which is described as servents in

the gnutella specification, and it's what i'm trying to do..)
And this is what happens:
SOMETIMES, when computer A sends through a socket 37bytes, Computer B
recieves 37bytes, and prints certain info about it.
Now, other more irritating TIMES, computer A has to send two Packet,
one first, then another, both 37bytes long , the Send function on
computer A Tells me, Hey! i sent 37bytes, and then, the same, So i Say,
OK, computer A sent 2 37b messages. Now the funny part is.. Computer B
says Hey! i recieve something.. It's 74bytes (37 * 2) long!!! So i

If you are using TCP, packet boundaries are not preserved. Better
learn to live with it. It won't change. You can also get your
37 byte packet received as 23 and 14 byte pieces. Well, actually
the splitting up is more likely to happen with much larger packets,
say, 8k, but it still can happen with packets the size you are sending.

this is crazy for me. Cant handle it.

LEARN TO HANDLE IT. Or use UDP, which has its own problems,
like duplicate packets, missing packets, and packets out of order.

Please Help!.

Gordon L. Burditt

 

[Alan Balmer]

i have this sort of server - client (which is described as servents in
the gnutella specification, and it's what i'm trying to do..)

Off topic here, where we discuss the C programming language. At a
guess, I'd say comp.unix.programmer would be more useful to you.

 

[Kenneth Brody]

i have this sort of server - client (which is described as servents in
the gnutella specification, and it's what i'm trying to do..)
And this is what happens:

[...send'ing two 37-byte packets may result in recv'ing one 74-byte packet...]
[...]

this is crazy for me. Cant handle it.

[...]

Sockets are OT for clc, so if you want specifics, you'll probably need
something like comp.unix.programmer.

However, imagine program A fwrite()ing 37 bytes twice, and program B
fread()ing 74 bytes. How is this different?

If you can't handle it, then you need to find someone else who can
handle it to write it for you.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[spip_yeah]

That behaviour is to be expected. As another poster said, TCP does not
preserve packet boundaries.

I would add that you should view a tcp connection as a stream. If you
are _always_ sending 37 bytes, then you should query the socket to know
if it has at least 37 bytes for you to consume, in which case you can
then perform a read for 37 bytes (and not more, since you want eat up
what should be part of your next read).

Otherwise, if you ever send more than one type of data, you should
consider adding a header to your data chunks specifying the size of the
chunk itself.

But this is off topic for this group.