🚀 go-pugleaf

Exactly. We've defined the protocol and everything. We just don't know when
to close the socket. It's all about timing. Here's how it goes:

Step 1:     (OnClientConnect) Accept incomming connection (non-blocking
socket)
Step 2:     (OnClientRead) Spawn a new thread to recieve data from WInsock
Buf
Step 3:     Process the packet or repeat step 2 until processing can be
preformed
            each time terminating the thread once packet processing is done.
Step 4:     Send the response once consolidated packet processing complete
Step 5:     Close the socket

The problem is step 5. In a non-threadblocking socket, calling
Socket->SendBuf or Socket->SendText is useless in determining the amount of
data that has actually been sent. All it will return is the number of bytes
it *can* send.

A solution (without converting to thread-blocking)is to find out the number
of bytes sent over the particular socket.

If you're curious as to why we are not using thread-blocking sockets it's
because they're memory innefficient. Assume we get 10000 connections. This
means that we have 10000 threads running on over n CPUs. And even if we run
an 8 CPU config, that still makes it 1250 threads per CPU. And it's
frightenningly expensive.

The way it's done now, a thread pool size can be set. Transactions get
queued for processing whenever that's possible.

Tharun.


"Hans Galema" <j.m.galema.dontusethis@maartens.nl> wrote in message
news:3eddbd08$1@newsgroups.borland.com...
> Tharun Pillay wrote:
>
> > Trouble is that we don't know when the *server* must close the
connection -
> > we are relying on a timout or the client terminating the connection -
which
> > is dodgy.
>
> If you design the protocol for communicating with the proxyserver you
could
> decide that the server closes the connection after having forwarded the
received
> data to the client.
>
> Hans.
>