Re: Handling multiple connections

It's actually very simple, at least in theory. Redesign your
function to not assume it will read the data in one call. This
is called event-driven programming and has been around
for more than 20 years... Basically, remember the state for
each connection and read all available data from the socket
each time select says the socket has more data. If you have
the data ready, you can forward it to a higher layer for
processing, and not necessarily from within that same
function - here's where it makes sense to have another
thread pick it up. If not, simply return without alerting your
processing thread.

Still, I do want to point out that select cannot scale beyond
64 concurrent connections in Windows... This may or may
not be an issue for you, I don't know.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"Søren Dreijer" <bleh@xxxxxxxx> wrote in message
news:%23IbyCN7OGHA.3360@xxxxxxxxxxxxxxxxxxxxxxx
Yesterday I realized a possible design flaw in my network library.

Currently, I have a single thread dedicated to handle receives from all
clients connected to my server. I use select() to see if new data has been
received, and then I loop through each socket and receive the actual data.

All data being sent by clients are prepended with a header that indicates
if
the data is compressed and the length of the data. I've made a function
which first reads the header, then reads the specified amount of bytes (as
indicated by the header). That is, the function doesn't return until
everything has been received.

However, I came to think about what happens if the header is received and
the client then disconnects or the transfer is mighty slow. The receiving
thread would then hang until the socket times out or all the data has been
received and thus delays receiving on the other readable sockets.

I see two solutions to this problem:

- When the client closes the connection, the recv() call fails instantly
(no
timeout) and I can continue with the other sockets. This doesn't solve the
problem of slow transfers, though. The thread would still wait for all
data
to be received before proceeding to the next readable socket.

- Creating a thread for each client connected to the server. This thread
is
then responsible for receiving only on that single socket. One drawback is
the number of context switches taking place when the number of clients
connected increase, but I'm not sure how big an impact this will have on
performance really.
Also, having a thread take care of a single socket makes it easier to do
more direct error handling specific to that socket.

What would you guys suggest?




.

Relevant Pages

  • Re: closing ASyncSocket
    ... I reread the help for the ShutDown() call. ... not close the socket, and resources attached to the socket will not be freed ... What if I want to Closethe connection to return resources. ... receiving side after I received the last data. ...
    (microsoft.public.vc.mfc)
  • Problem with a Socket server Opening/Accepting Many sockets and the GC running.
    ... listening on port 11000 and ready to take a new connection. ... I created the Listener socket, ... THen all is well and my clients can connect for about another 3900 ...
    (microsoft.public.dotnet.languages.csharp)
  • Handling multiple connections
    ... clients connected to my server. ... and then I loop through each socket and receive the actual data. ... which first reads the header, then reads the specified amount of bytes (as ... received and thus delays receiving on the other readable sockets. ...
    (microsoft.public.win32.programmer.networks)
  • Problem with a Socket server program opening/accepting many connections and the GC is running.
    ... listening on port 11000 and ready to take a new connection. ... I created the Listener socket, ... connection to be started by my clients. ... I have read all the GC stuff, and socket stuff. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: good name to dispatch events (naming convention)
    ... clients, sends them over to some broker, and then dispatches results/ ... instance of the Connection class is instantiated on the server for each ... a generic handler: ... read off socket. ...
    (comp.object)
Loading