[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: simple TCP socket question (maybe a bit OT)
From:       Arthur Griffith <arthur () belugalake ! com>
Date:       1999-11-29 21:34:46
[Download RAW message or body]

Oops. I was thinking at the TCP/IP level instead of the socket level. The
TCP/IP level almost always breaks the  message into blocks and puts them
back together on the receiving end. (An ethernet can't take more than 1500
bytes in one block.) The sockets also bust things up, which means you can
receive your message in parts. This happens with a non-blocking call to
recv(). A blocking call to recv() should get the whole message (but, you
still oughta check it).


At 09:00 PM 11/29/99 +0100, you wrote: 
>>>>
 
You should never rely on the data being received in one block. 
There could be any kind of problem during the transfer, like slow
connections, bad quality links with a lot of TCP resends and a total
breakdown of the connection as the worst case... 
IMHO a recoverable problem that causes a slowdown will likely split the
data (?) 
I'm not too familiar with good, stable socket programming either but AFAIK
with 
a select() && recv() loop until all data you expect has arrived or an error
occurrs you should be on the safe side. 
Implied question: am I right with this? 
-Malte 

aleXXX wrote: Hi, 
I'm doing a bit socket programming and I don't know exactly, if I sent some 
data (let's say usually about 1k, but always less than maybe 16k) at once
from 
my TCP-client to my TCP-server, can I be sure that if my server detects
that the 
client sent something using select(), the whole data block arrived at once ? 
Or is it possible that the 1k is split up and I have to read 2x512 bytes? 

Bye 
Alex --  570 Professoren glauben, da Atomunflle auch knftig immer nur
woanders passieren  

 



--
Arthur Griffith                  http://www.belugalake.com
arthur@belugalake.com

[prev in list] [next in list] [prev in thread] [next in thread]