Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 May : Re: Do TIdTCPClient connects and disconnects cause heavy CPU/Network load?
| Subject: | Re: Do TIdTCPClient connects and disconnects cause heavy CPU/Network load? |
| Posted by: | "PeaShooter_OMO" (jacquesv..@homemail.co.za) |
| Date: | Fri, 12 May 2006 22:15:07 |
Thank you
"Martin James" <mjames_falcon@dial.pipex.com> wrote in message
news:4461cc56$1@newsgroups.borland.com...
>> Can I TIdTCPClient.Connect, WriteLn, Disconnect every time I want the
> client
>> to send data to the TIdTCPServer.
>
> You *can*, but...
>
>> Does it cause heavy load on the CPU or Network or is it the preferred
>> way?
>
> CPU - not really.
> Network - more than it might.
>
> Preferred way? Depends on criteria <g>
>
> Connect/send/disconnect is a sort of way of sending messages over TCP.
> The
> connect/disconnect defines the start and end of each message. Ths is
> easy,
> often done and apallingly slow for small messages. Sending one byte over
> a
> high-latency connection takes *ages* since the 'connect' 3-way handshake
> and
> the 'disconnect' 4-way handshake has to take place over the links, often
> swamping any time spent on the actual data transmission.
>
> It's more usual to stay connected and use some sort of protocol to define
> each message. WriteLn, with it's terminating character/s, is one way.
>
> Some protocols, used for short bursts of high-bandwidth transfers, use
> both
> mechanisms, eg. HTTP. Connect/disconnect allows large numbers of clients
> to be served, providing the transfer-rate profile of each client is
> characterised as above, as is the case with human web users who have to
> read
> web pages before initiating the next exchange.
>
> The other problem with connect/disconnect protocols is that context is not
> easily stored on the server. With HTTP, this can mean state-driven
> servers
> and context stored on the client, (eg. in cookies or as extended URL
> data).
>
> Rgds,
> Martin
none