Handling thousands of TCP socket connections

[Phil Jenson]

I am try to evaluate the most efficient method of handling thousands of
simultaneous TCP connects each of which remain connected to the server for
hours and pass a small amount of data usually once a minute. The data
received is logged in a SQL Server database.

The only method I have found of reading each socket requires a thread for
each connection which blocks waiting for data. This appears to be very
inefficient as it will result in thousands of threads, each of which will
have a networkstream and reader object doing very little. Is this blocking
method the best/only method of reading data from a TCP socket?

I was thinking of implementing a queue of open sockets which I cycled
through checking if each had any data ready to handle, spawning off a thread
from a threadpool class to handle reading and logging of the data before
returning the socket to the queue. Is it possible to identify if a socket
has data ready to be read and how many bytes to read to prevent it from
blocking?

I can possibly do an inefficient variation of the above by keeping a time
stamp against each socket and using this to wait until there 'should' be
data available and then spawning a thread to read it but data is not always
passed each minute so would result in a degree of threads being blocked for
a duration.

Does anybody have a suggestion as to the best method?

Thanks

Phil...

[Mike Jansen]

Check out the static method Socket.Select() (assuming you are using .NET
framework).

Mike
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

I am try to evaluate the most efficient method of handling thousands of
simultaneous TCP connects each of which remain connected to the server for
hours and pass a small amount of data usually once a minute. The data
received is logged in a SQL Server database.

The only method I have found of reading each socket requires a thread for
each connection which blocks waiting for data. This appears to be very
inefficient as it will result in thousands of threads, each of which will
have a networkstream and reader object doing very little. Is this blocking
method the best/only method of reading data from a TCP socket?

I was thinking of implementing a queue of open sockets which I cycled
through checking if each had any data ready to handle, spawning off a thread from a threadpool class to handle reading and logging of the data before
returning the socket to the queue. Is it possible to identify if a socket
has data ready to be read and how many bytes to read to prevent it from
blocking?

I can possibly do an inefficient variation of the above by keeping a time
stamp against each socket and using this to wait until there 'should' be
data available and then spawning a thread to read it but data is not always passed each minute so would result in a degree of threads being blocked for a duration.

Does anybody have a suggestion as to the best method?

Thanks

Phil...

[Phil Jenson]

Thank you both for your suggestions, both seem to offer the solution I am
after.

I am particaulr interested in the IO Completion port threads. Does the
standard socket.BeginReceive use an IO Completion Port Thread? Can I simply
call this method for each and every socket I am handling on the basis it
will call the callback method using the threads in the standard threadpool
and it will only do so when data is avaiable or the socket closed?

Phil...
"Stelrad Doulton" <___@____.com> wrote in message
news:4P*************@newsfe1-gui.ntli.net...

In addition to looking at Socket.Select, have another look at the
ThreadPool. You will find that there are 2 types of thread that it will
service; worker threads and IO completion port threads. I have recently
finished a thread-per-client server app that uses long running async-reads
on a socket by socket basis to achieve what you are talking about. The
single CPU machine I have tested on will handle 1000 concurrent
connections on that basis.
"Mike Jansen" <mj**********@mail.com> wrote in message
news:uB**************@TK2MSFTNGP15.phx.gbl...

Check out the static method Socket.Select() (assuming you are using .NET
framework).

Mike
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

I am try to evaluate the most efficient method of handling thousands of
simultaneous TCP connects each of which remain connected to the server
for
hours and pass a small amount of data usually once a minute. The data
received is logged in a SQL Server database.

The only method I have found of reading each socket requires a thread
for
each connection which blocks waiting for data. This appears to be very
inefficient as it will result in thousands of threads, each of which
will
have a networkstream and reader object doing very little. Is this
blocking
method the best/only method of reading data from a TCP socket?

I was thinking of implementing a queue of open sockets which I cycled
through checking if each had any data ready to handle, spawning off a

thread

from a threadpool class to handle reading and logging of the data before
returning the socket to the queue. Is it possible to identify if a
socket
has data ready to be read and how many bytes to read to prevent it from
blocking?

I can possibly do an inefficient variation of the above by keeping a
time
stamp against each socket and using this to wait until there 'should' be
data available and then spawning a thread to read it but data is not

always

passed each minute so would result in a degree of threads being blocked

for

a duration.

Does anybody have a suggestion as to the best method?

Thanks

Phil...

[Phil Jenson]

I have done some more resarch and I beleive the standard socket.BeginReceive
does use Completion Ports, but I have also seen reference to the number of
IO Completion Port threads being around 1000. Is this correct? And will this
prevent scaling above 1000 sockets?

Whilst this wont be an imediate problem we could well get into 10-100
thoushand connections in the future. At a cerain point we will be look into
load balancing servers/routers to scale this further but 1000 connections
will prove a major limit very early on in the life of this project.

Thanks

Phil...

"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:ua**************@TK2MSFTNGP14.phx.gbl...

Thank you both for your suggestions, both seem to offer the solution I am
after.

I am particaulr interested in the IO Completion port threads. Does the
standard socket.BeginReceive use an IO Completion Port Thread? Can I
simply call this method for each and every socket I am handling on the
basis it will call the callback method using the threads in the standard
threadpool and it will only do so when data is avaiable or the socket
closed?

Phil...
"Stelrad Doulton" <___@____.com> wrote in message
news:4P*************@newsfe1-gui.ntli.net...

In addition to looking at Socket.Select, have another look at the
ThreadPool. You will find that there are 2 types of thread that it will
service; worker threads and IO completion port threads. I have recently
finished a thread-per-client server app that uses long running
async-reads on a socket by socket basis to achieve what you are talking
about. The single CPU machine I have tested on will handle 1000
concurrent connections on that basis.
"Mike Jansen" <mj**********@mail.com> wrote in message
news:uB**************@TK2MSFTNGP15.phx.gbl...

Check out the static method Socket.Select() (assuming you are using .NET
framework).

Mike
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
I am try to evaluate the most efficient method of handling thousands of
simultaneous TCP connects each of which remain connected to the server
for
hours and pass a small amount of data usually once a minute. The data
received is logged in a SQL Server database.

The only method I have found of reading each socket requires a thread
for
each connection which blocks waiting for data. This appears to be very
inefficient as it will result in thousands of threads, each of which
will
have a networkstream and reader object doing very little. Is this
blocking
method the best/only method of reading data from a TCP socket?

I was thinking of implementing a queue of open sockets which I cycled
through checking if each had any data ready to handle, spawning off a
thread
from a threadpool class to handle reading and logging of the data
before
returning the socket to the queue. Is it possible to identify if a
socket
has data ready to be read and how many bytes to read to prevent it from
blocking?

I can possibly do an inefficient variation of the above by keeping a
time
stamp against each socket and using this to wait until there 'should'
be
data available and then spawning a thread to read it but data is not
always
passed each minute so would result in a degree of threads being blocked
for
a duration.

Does anybody have a suggestion as to the best method?

Thanks

Phil...

[Stelrad Doulton]

Hi Phil,

Yeah BeginRecieve does use completion ports. Unfortunatly the solution does
not scale up past the max number allowed by the ThreadPool but this is
determined by the hardware on which you are running. Look at
ThreadPool.GetMaxThreads and ThreadPool.SetMinThreads. If and when you hit
1000 concurrent users switching to a dual CPU machine should double the
number of clients you can handle.
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:e2**************@TK2MSFTNGP14.phx.gbl...

I have done some more resarch and I beleive the standard
socket.BeginReceive does use Completion Ports, but I have also seen
reference to the number of IO Completion Port threads being around 1000. Is
this correct? And will this prevent scaling above 1000 sockets?

Whilst this wont be an imediate problem we could well get into 10-100
thoushand connections in the future. At a cerain point we will be look
into load balancing servers/routers to scale this further but 1000
connections will prove a major limit very early on in the life of this
project.

Thanks

Phil...

"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:ua**************@TK2MSFTNGP14.phx.gbl...

Thank you both for your suggestions, both seem to offer the solution I am
after.

I am particaulr interested in the IO Completion port threads. Does the
standard socket.BeginReceive use an IO Completion Port Thread? Can I
simply call this method for each and every socket I am handling on the
basis it will call the callback method using the threads in the standard
threadpool and it will only do so when data is avaiable or the socket
closed?

Phil...
"Stelrad Doulton" <___@____.com> wrote in message
news:4P*************@newsfe1-gui.ntli.net...

In addition to looking at Socket.Select, have another look at the
ThreadPool. You will find that there are 2 types of thread that it will
service; worker threads and IO completion port threads. I have recently
finished a thread-per-client server app that uses long running
async-reads on a socket by socket basis to achieve what you are talking
about. The single CPU machine I have tested on will handle 1000
concurrent connections on that basis.
"Mike Jansen" <mj**********@mail.com> wrote in message
news:uB**************@TK2MSFTNGP15.phx.gbl...
Check out the static method Socket.Select() (assuming you are using
.NET
framework).

Mike
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
> I am try to evaluate the most efficient method of handling thousands
> of
> simultaneous TCP connects each of which remain connected to the server
> for
> hours and pass a small amount of data usually once a minute. The data
> received is logged in a SQL Server database.
>
> The only method I have found of reading each socket requires a thread
> for
> each connection which blocks waiting for data. This appears to be very
> inefficient as it will result in thousands of threads, each of which
> will
> have a networkstream and reader object doing very little. Is this
> blocking
> method the best/only method of reading data from a TCP socket?
>
> I was thinking of implementing a queue of open sockets which I cycled
> through checking if each had any data ready to handle, spawning off a
thread
> from a threadpool class to handle reading and logging of the data
> before
> returning the socket to the queue. Is it possible to identify if a
> socket
> has data ready to be read and how many bytes to read to prevent it
> from
> blocking?
>
> I can possibly do an inefficient variation of the above by keeping a
> time
> stamp against each socket and using this to wait until there 'should'
> be
> data available and then spawning a thread to read it but data is not
always
> passed each minute so would result in a degree of threads being
> blocked
for
> a duration.
>
> Does anybody have a suggestion as to the best method?
>
> Thanks
>
> Phil...
>
>

[Phil Jenson]

Thanks for the information this has helped point me in a good direction to
evaluate further.

As I can "almost" anticipate when data will be available (because it comes
once a minute or somtime after) I may be able to delay initiating each
subesquent BeginReceive by a minute thus the number of pending reads at any
point in time will be considerably less, increasing the capacity
significatntly passed the thread limitation. It will probably be run on a
Quad Xeon server ultimatly

Thanks for the ideas.

Phil...
"Stelrad Doulton" <___@____.com> wrote in message
news:m5**************@newsfe6-win.ntli.net...

Hi Phil,

Yeah BeginRecieve does use completion ports. Unfortunatly the solution
does not scale up past the max number allowed by the ThreadPool but this
is determined by the hardware on which you are running. Look at
ThreadPool.GetMaxThreads and ThreadPool.SetMinThreads. If and when you hit
1000 concurrent users switching to a dual CPU machine should double the
number of clients you can handle.
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:e2**************@TK2MSFTNGP14.phx.gbl...

I have done some more resarch and I beleive the standard
socket.BeginReceive does use Completion Ports, but I have also seen
reference to the number of IO Completion Port threads being around 1000.
Is this correct? And will this prevent scaling above 1000 sockets?

Whilst this wont be an imediate problem we could well get into 10-100
thoushand connections in the future. At a cerain point we will be look
into load balancing servers/routers to scale this further but 1000
connections will prove a major limit very early on in the life of this
project.

Thanks

Phil...

"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:ua**************@TK2MSFTNGP14.phx.gbl...

Thank you both for your suggestions, both seem to offer the solution I
am after.

I am particaulr interested in the IO Completion port threads. Does the
standard socket.BeginReceive use an IO Completion Port Thread? Can I
simply call this method for each and every socket I am handling on the
basis it will call the callback method using the threads in the standard
threadpool and it will only do so when data is avaiable or the socket
closed?

Phil...
"Stelrad Doulton" <___@____.com> wrote in message
news:4P*************@newsfe1-gui.ntli.net...
In addition to looking at Socket.Select, have another look at the
ThreadPool. You will find that there are 2 types of thread that it will
service; worker threads and IO completion port threads. I have recently
finished a thread-per-client server app that uses long running
async-reads on a socket by socket basis to achieve what you are talking
about. The single CPU machine I have tested on will handle 1000
concurrent connections on that basis.
"Mike Jansen" <mj**********@mail.com> wrote in message
news:uB**************@TK2MSFTNGP15.phx.gbl...
> Check out the static method Socket.Select() (assuming you are using
> .NET
> framework).
>
> Mike
>
>
> "Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
> news:%2****************@TK2MSFTNGP15.phx.gbl...
>> I am try to evaluate the most efficient method of handling thousands
>> of
>> simultaneous TCP connects each of which remain connected to the
>> server for
>> hours and pass a small amount of data usually once a minute. The data
>> received is logged in a SQL Server database.
>>
>> The only method I have found of reading each socket requires a thread
>> for
>> each connection which blocks waiting for data. This appears to be
>> very
>> inefficient as it will result in thousands of threads, each of which
>> will
>> have a networkstream and reader object doing very little. Is this
>> blocking
>> method the best/only method of reading data from a TCP socket?
>>
>> I was thinking of implementing a queue of open sockets which I cycled
>> through checking if each had any data ready to handle, spawning off a
> thread
>> from a threadpool class to handle reading and logging of the data
>> before
>> returning the socket to the queue. Is it possible to identify if a
>> socket
>> has data ready to be read and how many bytes to read to prevent it
>> from
>> blocking?
>>
>> I can possibly do an inefficient variation of the above by keeping a
>> time
>> stamp against each socket and using this to wait until there 'should'
>> be
>> data available and then spawning a thread to read it but data is not
> always
>> passed each minute so would result in a degree of threads being
>> blocked
> for
>> a duration.
>>
>> Does anybody have a suggestion as to the best method?
>>
>> Thanks
>>
>> Phil...
>>
>>
>
>

[Willy Denoyette [MVP]]

Note that with the current version of the CLR you have a max of 1000 IOCP
threads per CPU in the pool.

Willy.

"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:e2**************@TK2MSFTNGP14.phx.gbl...

I have done some more resarch and I beleive the standard
socket.BeginReceive does use Completion Ports, but I have also seen
reference to the number of IO Completion Port threads being around 1000. Is
this correct? And will this prevent scaling above 1000 sockets?

Whilst this wont be an imediate problem we could well get into 10-100
thoushand connections in the future. At a cerain point we will be look
into load balancing servers/routers to scale this further but 1000
connections will prove a major limit very early on in the life of this
project.

Thanks

Phil...

"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:ua**************@TK2MSFTNGP14.phx.gbl...

Thank you both for your suggestions, both seem to offer the solution I am
after.

I am particaulr interested in the IO Completion port threads. Does the
standard socket.BeginReceive use an IO Completion Port Thread? Can I
simply call this method for each and every socket I am handling on the
basis it will call the callback method using the threads in the standard
threadpool and it will only do so when data is avaiable or the socket
closed?

Phil...
"Stelrad Doulton" <___@____.com> wrote in message
news:4P*************@newsfe1-gui.ntli.net...

In addition to looking at Socket.Select, have another look at the
ThreadPool. You will find that there are 2 types of thread that it will
service; worker threads and IO completion port threads. I have recently
finished a thread-per-client server app that uses long running
async-reads on a socket by socket basis to achieve what you are talking
about. The single CPU machine I have tested on will handle 1000
concurrent connections on that basis.
"Mike Jansen" <mj**********@mail.com> wrote in message
news:uB**************@TK2MSFTNGP15.phx.gbl...
Check out the static method Socket.Select() (assuming you are using
.NET
framework).

Mike
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
> I am try to evaluate the most efficient method of handling thousands
> of
> simultaneous TCP connects each of which remain connected to the server
> for
> hours and pass a small amount of data usually once a minute. The data
> received is logged in a SQL Server database.
>
> The only method I have found of reading each socket requires a thread
> for
> each connection which blocks waiting for data. This appears to be very
> inefficient as it will result in thousands of threads, each of which
> will
> have a networkstream and reader object doing very little. Is this
> blocking
> method the best/only method of reading data from a TCP socket?
>
> I was thinking of implementing a queue of open sockets which I cycled
> through checking if each had any data ready to handle, spawning off a
thread
> from a threadpool class to handle reading and logging of the data
> before
> returning the socket to the queue. Is it possible to identify if a
> socket
> has data ready to be read and how many bytes to read to prevent it
> from
> blocking?
>
> I can possibly do an inefficient variation of the above by keeping a
> time
> stamp against each socket and using this to wait until there 'should'
> be
> data available and then spawning a thread to read it but data is not
always
> passed each minute so would result in a degree of threads being
> blocked
for
> a duration.
>
> Does anybody have a suggestion as to the best method?
>
> Thanks
>
> Phil...
>
>

[John Vottero]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:OU**************@TK2MSFTNGP15.phx.gbl...

Note that with the current version of the CLR you have a max of 1000 IOCP
threads per CPU in the pool.
I don't understand what you mean. An IOCP isn't a thread. What is this
1000 limit? Does the CLR create a new thread for every 1000 objects sharing
an IOCP? I understand IOCPs and I understand that the CLR uses them but,
I'm not quite sure how the CLR uses them or what this limit of 1000 is.

Willy.

"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:e2**************@TK2MSFTNGP14.phx.gbl...

I have done some more resarch and I beleive the standard
socket.BeginReceive does use Completion Ports, but I have also seen
reference to the number of IO Completion Port threads being around 1000.
Is this correct? And will this prevent scaling above 1000 sockets?

Whilst this wont be an imediate problem we could well get into 10-100
thoushand connections in the future. At a cerain point we will be look
into load balancing servers/routers to scale this further but 1000
connections will prove a major limit very early on in the life of this
project.

Thanks

Phil...

"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:ua**************@TK2MSFTNGP14.phx.gbl...

Thank you both for your suggestions, both seem to offer the solution I
am after.

I am particaulr interested in the IO Completion port threads. Does the
standard socket.BeginReceive use an IO Completion Port Thread? Can I
simply call this method for each and every socket I am handling on the
basis it will call the callback method using the threads in the standard
threadpool and it will only do so when data is avaiable or the socket
closed?

Phil...
"Stelrad Doulton" <___@____.com> wrote in message
news:4P*************@newsfe1-gui.ntli.net...
In addition to looking at Socket.Select, have another look at the
ThreadPool. You will find that there are 2 types of thread that it will
service; worker threads and IO completion port threads. I have recently
finished a thread-per-client server app that uses long running
async-reads on a socket by socket basis to achieve what you are talking
about. The single CPU machine I have tested on will handle 1000
concurrent connections on that basis.
"Mike Jansen" <mj**********@mail.com> wrote in message
news:uB**************@TK2MSFTNGP15.phx.gbl...
> Check out the static method Socket.Select() (assuming you are using
> .NET
> framework).
>
> Mike
>
>
> "Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
> news:%2****************@TK2MSFTNGP15.phx.gbl...
>> I am try to evaluate the most efficient method of handling thousands
>> of
>> simultaneous TCP connects each of which remain connected to the
>> server for
>> hours and pass a small amount of data usually once a minute. The data
>> received is logged in a SQL Server database.
>>
>> The only method I have found of reading each socket requires a thread
>> for
>> each connection which blocks waiting for data. This appears to be
>> very
>> inefficient as it will result in thousands of threads, each of which
>> will
>> have a networkstream and reader object doing very little. Is this
>> blocking
>> method the best/only method of reading data from a TCP socket?
>>
>> I was thinking of implementing a queue of open sockets which I cycled
>> through checking if each had any data ready to handle, spawning off a
> thread
>> from a threadpool class to handle reading and logging of the data
>> before
>> returning the socket to the queue. Is it possible to identify if a
>> socket
>> has data ready to be read and how many bytes to read to prevent it
>> from
>> blocking?
>>
>> I can possibly do an inefficient variation of the above by keeping a
>> time
>> stamp against each socket and using this to wait until there 'should'
>> be
>> data available and then spawning a thread to read it but data is not
> always
>> passed each minute so would result in a degree of threads being
>> blocked
> for
>> a duration.
>>
>> Does anybody have a suggestion as to the best method?
>>
>> Thanks
>>
>> Phil...
>>
>>
>
>

[Stelrad Doulton]

In addition to looking at Socket.Select, have another look at the
ThreadPool. You will find that there are 2 types of thread that it will
service; worker threads and IO completion port threads. I have recently
finished a thread-per-client server app that uses long running async-reads
on a socket by socket basis to achieve what you are talking about. The
single CPU machine I have tested on will handle 1000 concurrent connections
on that basis.
"Mike Jansen" <mj**********@mail.com> wrote in message
news:uB**************@TK2MSFTNGP15.phx.gbl...

Check out the static method Socket.Select() (assuming you are using .NET
framework).

Mike
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

I am try to evaluate the most efficient method of handling thousands of
simultaneous TCP connects each of which remain connected to the server
for
hours and pass a small amount of data usually once a minute. The data
received is logged in a SQL Server database.

The only method I have found of reading each socket requires a thread for
each connection which blocks waiting for data. This appears to be very
inefficient as it will result in thousands of threads, each of which will
have a networkstream and reader object doing very little. Is this
blocking
method the best/only method of reading data from a TCP socket?

I was thinking of implementing a queue of open sockets which I cycled
through checking if each had any data ready to handle, spawning off a

thread

from a threadpool class to handle reading and logging of the data before
returning the socket to the queue. Is it possible to identify if a socket
has data ready to be read and how many bytes to read to prevent it from
blocking?

I can possibly do an inefficient variation of the above by keeping a time
stamp against each socket and using this to wait until there 'should' be
data available and then spawning a thread to read it but data is not

always

passed each minute so would result in a degree of threads being blocked

for

a duration.

Does anybody have a suggestion as to the best method?

Thanks

Phil...

[Stelrad Doulton]

In addition to looking at Socket.Select, have another look at the
ThreadPool. You will find that there are 2 types of thread that it will
service; worker threads and IO completion port threads. I have recently
finished a thread-per-client server app that uses long running async-reads
on a socket by socket basis to achieve what you are talking about. The
single CPU machine I have tested on will handle 1000 concurrent connections
on that basis.
"Mike Jansen" <mj**********@mail.com> wrote in message
news:uB**************@TK2MSFTNGP15.phx.gbl...

Check out the static method Socket.Select() (assuming you are using .NET
framework).

Mike
"Phil Jenson" <ph**@jenson.co.uk.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

I am try to evaluate the most efficient method of handling thousands of
simultaneous TCP connects each of which remain connected to the server
for
hours and pass a small amount of data usually once a minute. The data
received is logged in a SQL Server database.

The only method I have found of reading each socket requires a thread for
each connection which blocks waiting for data. This appears to be very
inefficient as it will result in thousands of threads, each of which will
have a networkstream and reader object doing very little. Is this
blocking
method the best/only method of reading data from a TCP socket?

I was thinking of implementing a queue of open sockets which I cycled
through checking if each had any data ready to handle, spawning off a

thread

from a threadpool class to handle reading and logging of the data before
returning the socket to the queue. Is it possible to identify if a socket
has data ready to be read and how many bytes to read to prevent it from
blocking?

I can possibly do an inefficient variation of the above by keeping a time
stamp against each socket and using this to wait until there 'should' be
data available and then spawning a thread to read it but data is not

always

passed each minute so would result in a degree of threads being blocked

for

a duration.

Does anybody have a suggestion as to the best method?

Thanks

Phil...