Newbie:Using ASP.NET thread pool thread to dispatch TCP data, etc.

[Navin Mishra]

Hi,

I've an ASP.NET web service which distributes events to clients via TCP.
Environment is IIS6 on Windows 2003 server with .NET framework 1.1 SP1. A
client registers with the web service passing its TCP port to send events to
and web service opens a TCP blocking socket to the client. Whenever the web
service needs to send an event to the client, it spawns a dynamic
non-persistent thread to dispatch event to the client over the connected
blocking socket.

Does THAT thread count in the configured thread limit of ASP.NET worker
process worker and I/O threads ? If not, can an ASP.NET thread pool
thread(I/O or worker) be used instead to dispatch event to the client to
avoid overhead of creating and destroying TCP event dispatching threads(I
wanted to dispatch event to the client as soon as it is received and so I
spawn a new thread everytime) ? If yes, would it be required to use
asynchronous sockets ? Is a web service needs to send TCP data to an
endpoint, is it affected by maxConnection parameter ?

Is it more optimal if, instead of web service opening TCP socket to client,
the client opens a TCP socket to the web service to get events via TCP ?
Then that means that web service needs to listen on a TCP port too on
another thread ?

Any advice and/or recommendations appreciated!

Thanks in advance and regards

Navin

 

[John Timney \(ASP.NET MVP\)]

Pretty sure it counts - and I think the limit is still 25 worker threads in
the pool, thus thats going to be your max consumers.

Why not have your service listen on port 80, let the web server do the
work.....

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

 

[Navin Mishra]

Thanks for response. Doesn't AppPool control the threads ? If I spawn a new
thread explicitly in the ASP.NET web service, I thought it would be separate
from thread pool threads and it won't count in the worker thread configured
limit. No?

I guess you meant web service listening on TCP port 80 in order to dispatch
events to connected clients. But the web site for web service is already
listening on port 80 for web service requests and would't it cause conflicts
as only one app could listen on a TCP port ? But yes the web service
listening port could be changed to be other than 80 but then there is issue
of firewall traversal. Also the payload on TCP port for events would not be
SOAP - it would be event information received from some provider.

Thanks again and regards

Navin

 

[John Timney \(ASP.NET MVP\)]

Perhaps I misread your question. ASP.NET threads do not come from the
thread pool, thread pool threads do not come from the app pool. The thread
pool is something you can create in the system to make available an explicit
pool of managed threads. So, if you create a thread pool within an aspx
request, and that pool opens a socket/make a web service request/ open a
file etc. from within a thread pool thread it consumes another thread from
within the current thread pool of 25 per cpu - not the same as app pool
threads that handle asp.net requests. I cant remember exactly why it does
this, but try it and see. Your web service itself can take thousands of
thread requests (handled by the app pool), so if your service is making
stateless request from a thread pool created within the web service method
call then the thread pool in theory should be created for each method call.
You'll have to experiment but I never recommend to anyone that they spawn
threads in an active asp.net process.

I hope that makes sense, I think I have it right!

IIS listens on default port 80 - your web app gets requests piped to it from
the web server via port 80. So, your clients could telnet to port 80 and
issue standard get request containing the information to a public webservice
method in any web application directly without wsdl files, or soap. I
suppose it depends on how flexible your client is in talking the http
protocol - or not.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director