RE: Best design pattern for a TCP "HUB" service
From: Peter Huang (v-phuang_at_online.microsoft.com)
Date: 02/18/05
- Next message: BBC1009: "Sql Server Timeout Problem"
- Previous message: Michael D. Ober: "Re: How many threads are there in this situation."
- In reply to: danavni_at_officecore.com: "Best design pattern for a TCP "HUB" service"
- Next in thread: danavni_at_officecore.com: "Re: Best design pattern for a TCP "HUB" service"
- Reply: danavni_at_officecore.com: "Re: Best design pattern for a TCP "HUB" service"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 18 Feb 2005 03:47:01 GMT
Hi
According to the MSDN below,
The number of threads a process can create is limited by the available
virtual memory. By default, every thread has one megabyte of stack space.
Therefore, you can create at most 2028 threads. If you reduce the default
stack size, you can create more threads. However, your application will
have better performance if you create one thread per processor and build
queues of requests for which the application maintains the context
information. A thread would process all requests in a queue before
processing requests in the next queue.
CreateThread
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas
e/createthread.asp
For the maximum socket a TCPLister can accept, in theory it is 2^32-1, we
can consider it as unlimited, because every time we create a socket, the
system will allocate kernel memory for the socket handle, so the accutal
account is hard to determine, because the other program will also use the
handle(e.g. file handle, gdi hanle ...) which will share the system kernel
memory.
In Socket programming, we have another term named backlog, which means the
connection request queue length before we accept it.
Use the Start method to begin listening for incoming connection requests.
Start will queue incoming connections until you either call the Stop method
or it has queued MaxConnections. Use either AcceptSocket or AcceptTcpClient
to pull a connection from the incoming connection request queue. These two
methods will block. If you want to avoid blocking, you can use the Pending
method first to determine if connection requests are available in the queue.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemnetsocketstcplistenerclasstopic.asp
Backlog Parameter
Windows Sockets server applications generally create a socket and then use
the listen() function on the socket to receive connection requests. One of
the parameters passed when using the listen() function is the backlog of
connection requests that the application would like Windows Sockets to
queue for the socket. The Windows Sockets 1.1 specification indicates that
the maximum allowable value for backlog is 5; however, Microsoft? Windows
NT? version 3.51 accepts a backlog of up to 100, Microsoft? Windows NT? 4.0
Server and Windows 2000 Server accepts a backlog of 200, and Microsoft?
Windows NT? 4.0 Workstation and Windows 2000 Professional accepts a backlog
of 5 (which reduces the memory footprint).
The backlog is usually used to consider the concurrent TCP connection
request.
Since newsgroup support did not provide advisory service, I just give some
general idea based on my knowlege.
If the maximum clients is not large, e.g. 100, you may try to use the first
design, because that is easy to implement, every client will have a
specified thread to do that.
While if the maximum client will be 1000 and more, according to the thread
count limitation, the second one will be OK. As a suggestion, if you want
to increase the performance, you may create more than one thread to query
the hashtable to handle the connection.
Best regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
- Next message: BBC1009: "Sql Server Timeout Problem"
- Previous message: Michael D. Ober: "Re: How many threads are there in this situation."
- In reply to: danavni_at_officecore.com: "Best design pattern for a TCP "HUB" service"
- Next in thread: danavni_at_officecore.com: "Re: Best design pattern for a TCP "HUB" service"
- Reply: danavni_at_officecore.com: "Re: Best design pattern for a TCP "HUB" service"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|