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.

[ Post a follow-up to this message ]

<ifmusic@gmail.com> wrote in message
news:1129772980.512537.137810@g49g2000cwa.googlegroups.com...

>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!.

This is expected behavior for TCP. TCP provides a byte stream that does
not preserve message boundaries. You if you send 37 bytes, whether you send
it in one call for all 37 or 37 calls for one each, you can receive it as
one receive for 37 or 37 receives for one each, or anything in-between.

Why can't you handle it?

DS

[ Post a follow-up to this message ]

Have a look at gnutella spec again, I'm sure it tells you how to work
out how long each message is (having started writing a gnutella prog
years ago out of interest).

16 byte header + some other crap + payload length + payload or
something like that.

[ Post a follow-up to this message ]

Hi,

> 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.

As pointed out by David, this is something perfectly natural with TCP.
In fact, when you send several messages they might be send physically
in one TCP segment (for efficiency reason).

This contrasts with UDP datagram, where 1 recv corresponds to 1 send.
One says in this case that "boundaries are preserved". TCP is a byte
stream protocol: it doesn't preserve message boundaries.

IOW, with TCP you must restore yourself the message boundaries.
When processing a TCP segment, you should be aware of the message
length (37 in your example). Thus if you got 74 bytes, you should
process the segment received as 2 messages.  =20


HTH,
Lo=EFc.

[ Post a follow-up to this message ]

loic-dev@gmx.net ha escrito:

> Hi,
> 
>
> As pointed out by David, this is something perfectly natural with TCP.
> In fact, when you send several messages they might be send physically
> in one TCP segment (for efficiency reason).
>
> This contrasts with UDP datagram, where 1 recv corresponds to 1 send.
> One says in this case that "boundaries are preserved". TCP is a byte
> stream protocol: it doesn't preserve message boundaries.
>
> IOW, with TCP you must restore yourself the message boundaries.
> When processing a TCP segment, you should be aware of the message
> length (37 in your example). Thus if you got 74 bytes, you should
> process the segment received as 2 messages.
>=20
>=20
> HTH,
> Lo=EFc.

ok, if that's TCP nature, then i'll check sizes.

[ Post a follow-up to this message ]