(socket) send transmits data on same packet

Hi all,

I noticed that when I use send() function to send data to remote PC,
I
see all the data on same packet (Wireshark) even though I used send
more than once.
For example,

send("er");
send("an");
send("ya");

I will see the data on same packet rether than 3 packets.


thanks.

(E-Mail Removed) wrote:
> Hi all,
>
> I noticed that when I use send() function to send data to remote PC,
> I
> see all the data on same packet (Wireshark) even though I used send
> more than once.
> For example,
>
> send("er");
> send("an");
> send("ya");
>
> I will see the data on same packet rether than 3 packets.


If you're using a stream socket (TCP), it is
perfectly normal.

TCP guarantees only that all octets (bytes) sent
eventually arrive at the destination in the same
order as they are sent.

There's no guarantee whatsoever of correspondence
of the socket write lengths and the lengths of the
packets on wire.

If you want to preserve record boundaries, you have
two options:

- Embed the record boundary markers or record
lengths into the TCP data stream, or

- use UDP (and be prepared for missing and/or mis-
ordered packets).

--

Tauno Voipio

On May 28, 11:25*am, alexia....@gmail.com wrote:
> Hi all,
>
> I noticed that when I use send() function to send data to remote PC,
> I
> see all the data on same packet (Wireshark) even though I used send
> more than once.
> For example,
>
> send("er");
> send("an");
> send("ya");
>
> I will see the data on same packet rether than 3 packets.
>
> thanks.

So what? TCP applications don't care about packets.

If you ask FedEx to send three packages to Asia, does it matter to you
whether they go on three trucks or one truck? (And wouldn't it be
really dumb to expect them to take three separate trucks if they all
fit in one truck?)

TCP implements a division of responsibility. Just as using FedEx means
you don't have to care how many trucks or planes the package takes,
using TCP means you don't have to care about how many packets the
bytes take.

Just as FedEx might route a package in a way that naively seems like
the long way (maybe the truck that went directly was full, maybe there
was a storm and the plane took a strange route), TCP sometimes gets
the data to the other side in ways that naively seem odd or wrong. In
this case, it's obvious why TCP did what it did. The total number of
bytes sent is lower this way because each packet has overhead.

If you care if your three packages all go in the same truck, you can't
use FedEx (because they don't guarantee this). But there is no reason
you should care. Similarly, if you care if your bytes go in the same
packet, you can't use TCP (because it doesn't guarantee this). But
there's no reason you should care.

DS