Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 May : Re: Do TIdTCPClient connects and disconnects cause heavy CPU/Network load?

www.cryer.info
Managed Newsgroup Archive

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

Replies:

none

In response to:

www.cryer.info
Managed Newsgroup Archive