Board index » delphi » Sending Long messages using TServerSocket or TClientSocket

Sending Long messages using TServerSocket or TClientSocket

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.

 

Re:Sending Long messages using TServerSocket or TClientSocket


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

Re:Sending Long messages using TServerSocket or TClientSocket


Quote
"Trevor Peacock" <Tre...@nevets.com.au> wrote in message

news:3a18b24c$1_2@dnews...

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

Have you considered using Indy (blocking sockets) or ICS (asynchronous
sockets)?

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

Re:Sending Long messages using TServerSocket or TClientSocket


I encountered the same problem. I managed to figure out a maximal limit of 8000
bytes (8192 to be precise)for the message one can send over a TServerSocket or
TClientSocket. This seems to be a limitation implemented in the winsock.dll
library.But nevertheless the message gets fragmentated at the application layer
anyway(I believe that the MTU(maximal transmission unit) is 1500 bytes for TCP
and 576 bytes for UDP) so if your app shoots messages smaller than this limit
then it shouldn't get messed up.
I preffer to keep my message down to 1024 bytes and do some sort of
acknowledgement between the sender and the recipient. I know it's redundant
since TCP does a  ACK operation but this way I can get my app to work.
Quote
Don wrote:
> "Trevor Peacock" <Tre...@nevets.com.au> wrote in message
> news:3a18b24c$1_2@dnews...

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

> Have you considered using Indy (blocking sockets) or ICS (asynchronous
> sockets)?

> 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

Re:Sending Long messages using TServerSocket or TClientSocket


I encountered the same problem. I managed to figure out a maximal limit of 8000
bytes (8192 to be precise)for the message one can send over a TServerSocket or
TClientSocket. This seems to be a limitation implemented in the winsock.dll
library.But nevertheless the message gets fragmentated at the application layer
anyway(I believe that the MTU(maximal transmission unit) is 1500 bytes for TCP
and 576 bytes for UDP) so if your app shoots messages smaller than this limit
then it shouldn't get messed up.
I preffer to keep my message down to 1024 bytes and do some sort of
acknowledgement between the sender and the recipient. I know it's redundant
since TCP does a  ACK operation but this way I can get my app to work.
Quote
Don wrote:
> "Trevor Peacock" <Tre...@nevets.com.au> wrote in message
> news:3a18b24c$1_2@dnews...

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

> Have you considered using Indy (blocking sockets) or ICS (asynchronous
> sockets)?

> 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

Re:Sending Long messages using TServerSocket or TClientSocket


Quote
"Denis Bujoreanu" <Den...@mercurypromo.ro> wrote in message

news:3A18DA4F.60E59B60@mercurypromo.ro...
Quote
> library.But nevertheless the message gets fragmentated at the application
layer
> anyway(I believe that the MTU(maximal transmission unit) is 1500 bytes for
TCP
> and 576 bytes for UDP) so if your app shoots messages smaller than this

limit

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

Re:Sending Long messages using TServerSocket or TClientSocket


From what I can remember the TCP specs states that the size of the packet is
actually negotiated during the handshake protocol and is recomputed if necesary
during the connection, thus providing a reliable and optimal speed over a
unreliable link.
I guess the app writer has to worry about fragmentation after all.
TCP is, sadly, not as reliable as it was ment in the first place.
Quote
Rune Moberg wrote:
> "Denis Bujoreanu" <Den...@mercurypromo.ro> wrote in message
> news:3A18DA4F.60E59B60@mercurypromo.ro...
> > library.But nevertheless the message gets fragmentated at the application
> layer
> > anyway(I believe that the MTU(maximal transmission unit) is 1500 bytes for
> TCP
> > and 576 bytes for UDP) so if your app shoots messages smaller than this
> limit

> 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

Re:Sending Long messages using TServerSocket or TClientSocket


This is how winsock works, changing the component will solve nothing, unless
it hides all the workings from the programmer. You need to send the data
until all the data is sent, you also need to receive the data until all the
data is received.

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

Quote
"Trevor Peacock" <Tre...@nevets.com.au> wrote in message

news:3a18b24c$1_2@dnews...
Quote

> ps. At this stage I am willing to change the method, eg. use  another

component (eg winsock.ocx) if it will fix the problem.
Quote

> 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

Re:Sending Long messages using TServerSocket or TClientSocket


Denis Bujoreanu <Den...@mercurypromo.ro> schreef in berichtnieuws
3A192FF6.2213...@mercurypromo.ro...
[snip]

Quote
> I guess the app writer has to worry about fragmentation after all.

With this I can fully agree...

Quote
> TCP is, sadly, not as reliable as it was ment in the first place.

...But this is definitely not true.
TCP/IP is the most reliable protocol you can get, but it is frequently
misunderstood.

-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!
---------------------------------------------------------

Re:Sending Long messages using TServerSocket or TClientSocket


Quote
"Paul Gertzen" <pgert...@livetechnology.com> wrote:
>This is how winsock works, changing the component will solve nothing, unless
>it hides all the workings from the programmer. You need to send the data
>until all the data is sent, you also need to receive the data until all the
>data is received.

>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

"Fix was the wrong word to use. "Get around" would have been
more appropriate.
Thankyou for your kind help. I'll sit down and figure out how
your example works.

Thankyou to everyone else who replied to my message.

Regards
  Trevor Peacock.

Other Threads