[Nel] Network Connections
Tom wright
thomas.wright1@ntlworld.com
Thu, 1 Mar 2001 08:48:29 -0000
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C0A22C.632195A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Guys/Gals,
Having followed your arguements so far, i though i would chuck in my 2 p =
worth.
1) i think you are going to find it very difficult to scale a server to =
5000 concurrent users, using any kind of scheme unless its a BIG server. =
Look at EQ currently, they struggle with 2000. But this is just my =
opinion :-) so feel free to ignore it.
2) On windows NT/2k, using async sockets with events is a very efficent =
way of handling socket comms, and its quite easy to demultiplex the =
events to work out which socket caused the event. I would recommend =
this route, as one thread could then wait for events to be generated on =
say 30 sockets and then take appropriate action. unfortunately i can =
not tell you how well this is going to scale :-( Just look up WSAEvents =
for READ, SEND and CLOSE. It does make your sending more entertaining =
however :-)
3) Windows did support something called micro threads, which had a much =
lower over head than traditional threads. These ( if i remember =
correctly ) were designed specifically for scalable IO ( as in IIS ). =
Some time looking here may well yield some useful results.
4) Some OS's have limits to the size of the array to select, Windows is =
one of them, typical values seem to be 64. However using values this =
large, you are going to spend time thrashing the array looking for the =
source of the select, with events this is much easier and quicker, tho =
not linux compatible. Wrapping up the comms like this specific to each =
platform is not going to be to hard, just code to a common interface.
Regards
Tom
PS A binary of the next release for windows would be nice, takes HOURS =
to build :-)
------=_NextPart_000_000B_01C0A22C.632195A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Guys/Gals,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Having followed your arguements so far, =
i though i=20
would chuck in my 2 p worth.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>1) i think you are going to find it =
very difficult=20
to scale a server to 5000 concurrent users, using any kind of scheme =
unless its=20
a BIG server. Look at EQ currently, they struggle with 2000. =
But=20
this is just my opinion :-) so feel free to ignore it.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>2) On windows NT/2k, using async =
sockets with=20
events is a very efficent way of handling socket comms, and its quite =
easy to=20
demultiplex the events to work out which socket caused the event. =
I would=20
recommend this route, as one thread could then wait for events to be =
generated=20
on say 30 sockets and then take appropriate action. unfortunately =
i can=20
not tell you how well this is going to scale :-( Just look up =
WSAEvents for=20
READ, SEND and CLOSE. It does make your sending more entertaining =
however=20
:-)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>3) Windows did support something called =
micro=20
threads, which had a much lower over head than traditional =
threads. These=20
( if i remember correctly ) were designed specifically for scalable IO ( =
as in=20
IIS ). Some time looking here may well yield some useful=20
results.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>4) Some OS's have limits to the size of =
the array=20
to select, Windows is one of them, typical values seem to be 64. =
However=20
using values this large, you are going to spend time thrashing the array =
looking=20
for the source of the select, with events this is much easier and =
quicker, tho=20
not linux compatible. Wrapping up the comms like this specific to =
each=20
platform is not going to be to hard, just code to a common=20
interface.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Tom</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>PS A binary of the next release for =
windows would=20
be nice, takes HOURS to build :-)</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_000B_01C0A22C.632195A0--