From 0ea5fc66924303d1bf73ba283a383e2aadee02f2 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 20:21:34 +0200 Subject: Initial commit --- pipermail/nel/2001-March/000315.html | 174 +++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 pipermail/nel/2001-March/000315.html (limited to 'pipermail/nel/2001-March/000315.html') diff --git a/pipermail/nel/2001-March/000315.html b/pipermail/nel/2001-March/000315.html new file mode 100644 index 00000000..fdb24fb0 --- /dev/null +++ b/pipermail/nel/2001-March/000315.html @@ -0,0 +1,174 @@ + + + + [Nel] Network Connections + + + + + + +

[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>&nbsp;</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>&nbsp;</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.&nbsp; Look at EQ currently, they struggle with 2000.&nbsp; =
+But=20
+this is just my opinion :-) so feel free to ignore it.</FONT></DIV>
+<DIV>&nbsp;</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.&nbsp; =
+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.&nbsp; unfortunately =
+i can=20
+not tell you how&nbsp;well this is going to scale :-( Just look up =
+WSAEvents for=20
+READ, SEND and CLOSE.&nbsp; It does make your sending more entertaining =
+however=20
+:-)</FONT></DIV>
+<DIV>&nbsp;</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.&nbsp; These=20
+( if i remember correctly ) were designed specifically for scalable IO ( =
+as in=20
+IIS ).&nbsp; Some time looking here may well yield some useful=20
+results.</FONT></DIV>
+<DIV>&nbsp;</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.&nbsp; =
+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.&nbsp; 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>&nbsp;</DIV>
+<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
+<DIV>&nbsp;</DIV>
+<DIV><FONT face=3DArial size=3D2>Tom</FONT></DIV>
+<DIV>&nbsp;</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>&nbsp;</DIV>
+<DIV>&nbsp;</DIV></BODY></HTML>
+
+------=_NextPart_000_000B_01C0A22C.632195A0--
+
+
+
+ + + + + + + + +
+

+ -- cgit v1.2.1