Ive been working on a little project lately to test communication between one computer and another through the internet. This was a great opportunity to use BlakeNet. The plan was to host a daemon process that listens on a given port, accept incoming communication requests, and reply to messages sent to the server. The server program was programmed in Java, and the client program was originally programmed in Flash, but later I decided to create a second version in Java.
Working on this project brought up an interesting quirk about multi-user applications, though. It turns out, in the case of Java, at least, that ports can only have one persistent connection at a time. All other connection requests on that port are queued, and are only allowed to open once the current connection closes. There are a couple different ways of getting over this problem. Im still considering which one to implement.
The first is to have the server continue to listen on one port, and have the server constantly kill the current connection, accept the next one in the queue, communicate, kill it, and repeat. This means the clients, in order to have semi-persistent connections, would have to send in another connection request each time the current one is killed. The problems with this is it has the possibility of being very bandwidth- and cpu-intensive, may lead to "greedy clients" who skip ahead of others in the queue and cause them to get more attention than other clients, and might lead to a loss of clients since theres a limit of 50 (or less, depending on the operating system) connection requests per queue.
The second is to have the server listen on one port for connection requests, then assign each request to its own port. This is probably the best way to go, but it does have its pitfalls. The biggest one is that having so many ports open, and only having one program to maintain all of them, can be a disaster to processing speed. The other, less significant problem is that there are only so many ports you can use. Ports 0-1023 are registered for use with system protocols and require superuser privileges to use, and ports 1024-49151 are registered for use with commercial programs. This means, under the worse-case-scenario, only 16382 or less connections can be allowed (ports 49152–65535, minus one for the connection request port). That is way more than needed, probably. But, limits are limits.
The third is to just create a peer-to-peer style application. The server will only be responsible for registering clients, and telling other clients of where to find them. All actual communications will be done between the clients themselves. This can lead to the client computers lagging and also leaves a lot of things up to the client to configure, especially security-wise. This is also similar in structure to the first proposed solution. So, this choice is definately out.
I think the best way to go is the second choice.
