AgNet - silverware Networking Interface Kit
by silver Harloe
Doc Index
Features and Advantages of AgNet
-
Accepts up to 57600 users (though configuration can greatly affect this).
Some future listener types suitable mostly for chat will essentially have no
user limit, and there is a future possibility of chaining servers up to 10
levels deep, which is more than enough to accept every computer on the net
connected at once (240^10 is a big number).
-
Accepts telnet connections in character at a time mode or line at a time mode.
-
Accepts raw TCP connections with no restrictions on data transfer (in terms
of content - realistically there are time/bandwidth restrictions of course).
-
At a cost in the user limit, a combination of all the acceptance modes
mentioned above could be used at once, with the server being able to treat
them all pretty much equally (though it might wish to send data to some
connections differently, anyway, it need not change the communication code
to do so)
-
Your server can be written in C or Perl, with future plans to support Java and
C++ and no reason support could not be added for any other language with
simple socket capabilities (actually, Perl support is only 15% finished as of
this writing, but progress on that will be fast once I get more documentation
written).
-
Can save 4044 bytes of data per user while the server goes offline, and get
it back when the server returns, thus allowing state-restoration of users.
This means you could effectively upgrade your server without disconnecting
users.
-
The server can be on a different machine from the host accepting user
connections, which can solve proxy and firewall issues and possibly make
system load less of a problem.
-
As work on the multiplexer and listener suite progresses, you will be able to
accept connections via ssh, relay text through systems like ICQ, AIM, etc, and
have IPv6 support, all without changing any code in your server. You get to
concentrate on the 'personality' of your service and let us do the networking.
-
You need not Open Source (or even distribute) your server code, and may charge
for service if you desire, with no licensing fee.
-
Existing MUD clients work fairly well with the telnet-line-at-a-time listener
mode, but if your primary communication channel is text, you need not require
clients at all (which would be handy if your MUD client doesn't, say, support
ssh communications because, say, the MUD does support ssh because it's a pain
to write).
-
A server based on AgNet would potentially be a really good way to greatly
increase the number of users who could connect to a system for locating and
establishing the peer to peer communications needed for people to play
high-bandwidth games or transfer files.
Disadvantages
-
Right now, you'd be the guinea pig. I'd try to help if you find any bugs, but
I can't guarantee service reliability until I write a real server and start
using it more myself (which I will do eventually, but currently want to add a
few features and lots of documentation to AgNet).
-
If your networking handling code is poorly centralized, it may be difficult to
upgrade an existing server to use AgNet (though you'd only have to do it once,
and then you could swap back by reimplementing calls to AgNet functions, and
your networking handling would be centralized).
-
If your server needs to do stuff more than once a second or whenever user
input is received, it is harder to use AgNet (i.e. you'd have to override more
hooks in the baseserver or roll your own server). If this becomes an issue, I
may modify the multiplexer config to be able send tick messages more often.
-
The level of indirection can increase memory usage and slow communications
down somewhat. The extra processes may increase system load unacceptably.
-
Fixing networking bugs would become a matter of deciphering someone else's
code, or else waiting for patches, which may be inconvenient if I have any
doozies in there.
-
Documentation is lacking (this is being worked on furiously right now, of
course).
-
Does not help multi-threaded servers tremendously (in fact, if you thread per
user right now, the multiplexer would actually become a bottleneck as you'd
need to synchronize communications with it to keep messages from intermixing).
-
Does not handle transfer of large chunks of data very well (if you were to
send 200 4k messages to a single user all in one function call, all those
messages would have to be sent, processed, and relayed before any other
message could be sent to another user). There are ways to code around this,
but they would involve your coding an output buffer (potentially one per
user), and this may be painful in memory usage and would certainly slow the
transfer down (not that you wouldn't have this problem on a regular server if
it were not multi-threaded, AgNet would certainly exacerbate the issue).
-
No load-balancing is expressed or implied. I think to do that I'd have to do
more than allow multiplexers to chain, but also give them a way of
communicating with each other about who gets to activate listeners, and get
them to coordinate clientkeys (though load balancing doesn't help unless you
have multiple servers, so if you dedicated a server to each multiplexer, there
wouldn't be clientkey issues, anyway).
In my personal opinion, several of these disadvantages exist for any chat/MUD
like system using a central communications channel. Threading a regular chat
creates text synchronization headaches, so most are not threaded, and, as a
result, were going to have issues with large-communications chunks potentially
'freezing' the other users, anyway. I'd be interested in how existing MMORPG
servers deal with these issues - AgNet certainly has the 'potential' of being
usable for a MMORPG. Though you'd still have bandwidth and server-speed
issues.
In any case, I'll be able to speak more about the quality of usage of AgNet
once I or someone else starts using it to front-end a server.
Doc Index