Re: MsgCommunicator v.2.00: Instant Messenger SDK, now with databases support



"Mike Shkolnik" wrote:
> PS: also just for interest - as I understand, the web-server (created with
> your components) will not work if 64K users will login, isn't?

HTTP doesn't need a persistent connection to serve a Client, it needs a
connection only for the duration of a request/response process. After that,
connection can be closed and will be opened automaticaly with next request.
This way, HTTP servers can handle a lot more clients than servers which
expect persistent connections.

Also, using a "backlog", new connections will be put inside a queue, where
they will wait for the server to pick them up. If Server was too busy doing
other things for too long, connections would be dropped after a specific
period of time. RTC uses a separate thread for accepting new connections, to
reduce the possibility of connections dropping when the Server is budy doing
other things.

> Also if you use the own cache and store the session id some time (30
> minutes, for example), then your web-server can't process the request from
> 64K users per this time (30 min in my sample). Or I missed something?

Sessions don't block execution.

Sessions are simply objects storing client-related data, associated with a
"Session ID". Sessions have a timeout period, after which all data related
to a specific session will be removed from memory, in case it wasn't needed
for a long time (user-defineable period in seconds). Each Session's timeout
counter is reset each time a session is in use, to ensure that sessions will
remain "alive" for as long as they are needed.

If you would use 30 minutes as Session Timeouts, this would only mean that
your Clients can stay "off-line" for about 30 minutes before they have to
connect to "ping" the server (which is usualy done by sending a normal
request).

Also, RTC SDK uses a Thread Pool mechanism (activated simply by setting the
MultiThreaded property to True) to make it possible for multiple connections
to process data at the same time. For example, by using a pool of 256
threads (default for RTC SDK), your server will be able to process 256
requests *simultaneously*. This can be increased to anything Windows can
handle (I wouldn't go higher than 1.000, to leave some resources for other
running applications), in case your server has to process a very high number
of very long lasting requests (for example, execute complex calculations
using databases) and you don't want to have your clients waiting in a queue.

If RTC Server should have to process more requests at the same time than
there are threads in a thread pool and pool size limits have alreadybeen
reached, requests will be placed in a queue and processed when any thread
from a pool completes a job which it was currently doing.

This way, using a limited number of threads and a limited number of active
connections, RTC Server can handle almost unlimited number of clients.

But, Messenger Client/Server applications are a specific sort, because
clients expect to get their messages almost instantly. To avoid flooding the
network with "ping" requests from all clients to check for new messages,
I've decided to use one non-pressistent connection for sending messages to
the server and a separate semi-persistent connection for receiving new
messages from the server. This can be changed to the "ping" method, if your
Messenger Server should have to handle more than 30K clients, while your
bandwidth and Server CPU usage isn't as important (which will be increased
because of often "ping" requests).

--
Danijel Tkalcec
http://www.deltasoft.hr/rtc/author.htm

RealThinClient components
-------------------------------------------
* The Easiest way to build Internet-enabled applications
- Clients, Stand-alone Servers, ISAPI extensions -
> Write and Call Remote Functions
> Download and Upload Files
> Single- and Multi-Threaded mode
> Firewall friendly - all over HTTP
> Stress-tested for highest stability

http://www.deltasoft.hr/rtc
http://www.deltasoft.hr/rtc/forum


.



Relevant Pages

  • Re: Problem with a Socket server program opening/accepting many connections and the GC is running.
    ... Yes your book is half right - it is 5 pending requests max on Workstation ... server OS if you want to do high capacity server stuff. ... clients connect and then stay connected ... As far as garbage collection killing things, ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Application design question
    ... system where clients can register with the server ... The server would then keep track of these requests and everytime the data ... scheduler component first (one that can fire events based on ...
    (microsoft.public.dotnet.languages.csharp)
  • sockets, closing and TIME_WAIT
    ... During heavy load the server can't follow anymore because the sockets ... my server should be able to handle 10 clients connecting ... This gets a free position in the array of connections, ...
    (comp.unix.programmer)
  • Re: TCP/IP redundant connections
    ... The clients have persistent TCP connections to the server, ...
    (freebsd-hackers)
  • Re: Intermittent Network Connections
    ... I've just reconnected the Server LAN nic 1 to the ethernet switch (the same ... Server IP config and Client IP config attached. ... > turn is connected to an ADSL modem out to the internet The clients connect to ... >> Clients can sucessfully log in but periodically loose their connections. ...
    (microsoft.public.windows.server.sbs)