Topic: Some remarks about the raptornl design.

[Jove]

Hi,

I took a quick look over the code in svn and have a few remarks I'd like to make.

I am not sure if you wish to use the raptornl code for both client and server, but I've seen a few things I have my doubts about regarding efficiency and scalability. First of all you use select() extensively in the code. This has a few distinct disadvantages:

• You are limited to a fixed number of file descriptors (default for linux this is 1024, on windows this is 64)
• You must manipulate fdsets even if only polling a single fd

Most of these are solved by using poll() on unix.
For windows it seems Completion Ports are the answer. I have no experience with these though.

From what I can see there is also no way to do any sort efficient input polling. The only way to know if any socket has data is to poll them all. This is only acceptable if you only have a few sockets.

[contingencyplan]

Interesting points. I haven't had a lot of time this semester to really learn socket programming to start RaptorNL off strong, so I can't reply specifically to the points you make. I'll look up the functions you reference during this thanksgiving break, though.

One thing to keep in mind is that the code we have, though we're refactoring it, is still 99% based off of HawkNL, which is a working networking library. Perhaps it has the same shortcomings, but I would think someone would have run into these problems in their own code and started talking about it.

[Jove]

I am sure the HawkNL works, but is it used for servers too? Most of the things I mention are only important for the server side of the connection. As a client you won't need more than a few sockets... but the server will need the same amount of sockets per client.

[Morgul]

HawkNL is actually used for both server and client applications. Now, I doubt it's been used as a MMORPG server, or anything super intense like that. I actually don't know how many large scale servers apps it has been used for; most only have one socket per client I would think, and have less than fifty clients at any one time, and are using tcp, so there this might have gone unnoticed for a while.

[contingencyplan]

Hence why we're rewriting it, and definitely appreciate people like Jove pointing out flaws and shortcomings.