I am using TServerSocket and TClientSocket components to send
lots of information from one computer to another. When I do
this, firstly the message is cut up in to pieces. It is sent as
one string but recieved in sections. I have got around this by
sticking  a number at the start so when it is received it can
wait for enough information to fill this amount of data. This
works, but when I further increase the amount of information,
not all of it is received. I dont know where these pieces are
(start middle end of string) but I end up with on average just
over half of what I sent. If anyone knows why this happens or
how to fix - get around it without significantly reducing speed.

Any information greatly appreciated.
Regards,
     Trevor Peacock.

ps. At this stage I am willing to change the method, eg. use  another component (eg winsock.ocx) if it will fix the problem.

I understand the TCP protocol automatically cuts up long
messages and assembles them again before your program receives
them. If ayone has any information, Please let me know.

Thankyou

I use Indy, and it works very well.  Indy provides client protocol
implementations for TCP, UDP, SMTP, HTTP, FTP, NNTP, and others.  There are
also server implementations for most of the protocols.  And a whole lot of
other useful stuff, too.<g>

The main point is that Indy provides methods that wrap up a lot of the
low-level protocol handling some other libraries require.  You just call
methods like WriteLn, WriteString, WriteStream, ReadLn, ReadString,
ReadStream, AllData, etc.

I tried ICS, but could not come to terms with the async socket event
handlers.

Indy can be downloaded from http://www.nevrona.com/indy/.
ICS can be downloaded from http://www.rtfm.be/fpiette/.

hth...

Don

The MTU usually defaults to 1500, yes. Windows have had (still have?)
problems determining MTU in certain situations. Sometimes routers prefer a
smaller MTU, and the OS needs to accomodate these routers to a great extent.
There are several methods that can be employed to determine MTU, and MS
hasn't always chosen the methods that certain router vendors prefer. There
should be some KB articles around which covers these problems in greater
depth... (ah, found it)

http://support.microsoft.com/support/kb/articles/Q159/2/11.asp

--
Rune

Winsock will send as much data as possible (reliant on the network) per send
and then return how much was actually sent.

BytesSent := 0;
While BytesSent < BytesToSend Do
 BytesSent := BytesSent + ClientSocket1.Socket.SendBuf(Buffer[BytesSent],
BytesToSend - BytesSent);

I have sent you an example of uploading a file using
tclientsocket/tserversocket. there is no data size limitation.

Paul

-No matter _what_ component you use, if you send large amounts of data, they
will be fragmented into packets of a few Kb, depending on the network(s)
they must travel through.

-TCP/IP does not care at all about "messages", "records" ,"files", or
whatever you choose to transmit.Therefore, it is up to the _applications_ at
both sides to reassemble these packets or groups of packets back into
meaningful data, as defined _by_ those applications.

- Think about it: Say you want to send 100Kb of data over the internet.
These data will be chopped up in, say, 25 packets in your ISP' router,
travel through 10 different networks, may take 2 or 3 _different_ routes,
and will finally arrive in say, 34 packets at the destination IP. Now
how_on_earth can the receiving TCP stack know that the last packet has
arrived? The answer is simple: it _cannot_ know, since there is always a
chance that still another packet was delayed and may arrive soon... so the
best thing TCP can do, is to hand over all packets to the application level
as soon as they arrive.

- TCP/IP is only what it was _designed_ to be: a reliable bytestream, upon
which you can build applications.

--
Regards,

Dirk Claessens
---------------------------------------------------------
http://www.claessens16.yucom.be
Attention: All spamshields raised; E-mails will bounce!
---------------------------------------------------------

Thankyou to everyone else who replied to my message.

Regards
  Trevor Peacock.