|
|
 |
 |
 |
 |
Number of bytes when receiving packets using C++
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
On 6/6/2007 3:38 PM, jaco.versf@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
On Jun 6, 8:38 pm, jaco.versf@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.) > 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.
Thank you very much to all who replied Kind Regards, Jaco
On Jun 6, 6:38 am, jaco.versf@gmail.com 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
On 8 Jun, 04:58, David Schwartz <dav@webmaster.com> wrote: > On Jun 6, 6:38 am, jaco.versf @gmail.com 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
|
 |
 |
 |
 |
|