Number of bytes when receiving packets using C++

[jaco.versfeld]

Hi There,

I have a basic TCP client and TCP server in C++. The TCP client
connects to the server, and after a setup phase starts to transmit a
file to the TCP server using multiple packets (fixed amount of bytes,
except for the last packet). This is accomplished by using a for loop
and the "int send(socket, buffer, bufferlength, 0)" function.

When I read the packets using "int recv(socket, buffer, 1500, 0)" the
number returned by the function is 1500, although the "data" packets
that I have sent each contains less bytes (1310 bytes). It seems that
with each recv() function, I get 1500 bytes from the network buffer,
and that I have lost "synchronisation" - I don't read packet for
packet, but a chunk of the network buffer. Is this the normal
operation of TCP, or did I break something along the way? (I would
hope that each recv function would return 1310, the size of the
original packet.)

Any help, suggestions and comments will be greatly appreciated
Jaco

[Stefan Naewe]

On 6/6/2007 3:38 PM, ja***********@gmail.com wrote:

Hi There,

I have a basic TCP client and TCP server in C++. The TCP client
connects to the server, and after a setup phase starts to transmit a
file to the TCP server using multiple packets (fixed amount of bytes,
except for the last packet). This is accomplished by using a for loop
and the "int send(socket, buffer, bufferlength, 0)" function.

When I read the packets using "int recv(socket, buffer, 1500, 0)" the
number returned by the function is 1500, although the "data" packets
that I have sent each contains less bytes (1310 bytes). It seems that
with each recv() function, I get 1500 bytes from the network buffer,
and that I have lost "synchronisation" - I don't read packet for
packet, but a chunk of the network buffer. Is this the normal
operation of TCP, or did I break something along the way? (I would
hope that each recv function would return 1310, the size of the
original packet.)

This is pretty OT in comp.lang.c++. Ask in comp.unix.programming for example.

But I tell you:
TCP is stream based. There are now record borders (you'd use UDP
for that). You have to transmit the record size in your packet
structure.

Regards,
Stefan
--
Stefan Naewe stefan dot naewe at atlas-elektronik dot com
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

[Inso Reiges]

On Jun 6, 8:38 pm, [e-mail] wrote:

Hi There,

I have a basic TCP client and TCP server in C++. The TCP client
connects to the server, and after a setup phase starts to transmit a
file to the TCP server using multiple packets (fixed amount of bytes,
except for the last packet). This is accomplished by using a for loop
and the "int send(socket, buffer, bufferlength, 0)" function.

When I read the packets using "int recv(socket, buffer, 1500, 0)" the
number returned by the function is 1500, although the "data" packets
that I have sent each contains less bytes (1310 bytes). It seems that
with each recv() function, I get 1500 bytes from the network buffer,
and that I have lost "synchronisation" - I don't read packet for
packet, but a chunk of the network buffer. Is this the normal
operation of TCP, or did I break something along the way? (I would
hope that each recv function would return 1310, the size of the
original packet.)

Any help, suggestions and comments will be greatly appreciated
Jaco

This is OT here, you would probably get better answers elsewhere.
But, as far as i know, tcp read\write is streamed. The way, i would
go, is design a simple protocol on top of TCP with a field for record
lenght.

[jaco.versfeld]

Thank you very much to all who replied

Kind Regards,
Jaco

[David Schwartz]

On Jun 6, 6:38 am, [e-mail] wrote:

I have a basic TCP client and TCP server in C++. The TCP client
connects to the server, and after a setup phase starts to transmit a
file to the TCP server using multiple packets (fixed amount of bytes,
except for the last packet). This is accomplished by using a for loop
and the "int send(socket, buffer, bufferlength, 0)" function.

Your bad terminology is going to cause you no end of pain. You are
using the term "packets" when you mean "records".

When I read the packets using "int recv(socket, buffer, 1500, 0)" the
number returned by the function is 1500, although the "data" packets
that I have sent each contains less bytes (1310 bytes).

You are probably sending 1,310 byte records in 1,500 byte packets (or,
more precisely, packets that hold up to 1,500 bytes of application
data).

It seems that
with each recv() function, I get 1500 bytes from the network buffer,
and that I have lost "synchronisation" - I don't read packet for
packet, but a chunk of the network buffer. Is this the normal
operation of TCP, or did I break something along the way?

If you call 'recv' fast enough, and no packets are lost, you *will*
receive packets. However, packets are not records.

(I would
hope that each recv function would return 1310, the size of the
original packet.)

Except that wasn't the size of the original packet, that was the size
of the original record.

Any help, suggestions and comments will be greatly appreciated

Don't call a record a packet. Sloppy terminology is your main problem.

You are sending records and receiving data as it becomes available
(which is going to be in chunks of packets).

DS

[Nick Keighley]

On 8 Jun, 04:58, David Schwartz <[e-mail]:

On Jun 6, 6:38 am, [e-mail] wrote:

I have a basic TCP client and TCP server in C++. The TCP client
connects to the server, and after a setup phase starts to transmit a
file to the TCP server using multiple packets (fixed amount of bytes,
except for the last packet). This is accomplished by using a for loop
and the "int send(socket, buffer, bufferlength, 0)" function.

Your bad terminology is going to cause you no end of pain. You are
using the term "packets" when you mean "records".

or go the whole hog and call 'em PDU's

:-)

<snip>
--
Nick Keighley