There''s been a bit of talk about getting more than 900/1000/1400 sockets lately, so I thought I''d post my current solution and see if people have a better ways of doing this. Right now, my limit is 1200 sockets on Linux RH 7.1. I can get up to 1400, but I usually lose 200 sockets pretty quick. Here''s what I did. I split up the server into one main server with all the logic and everything and sub-servers that handle connections above 1000. When the client connects to the main server and it''s full (over 1000 connections), it sends back the IP of the 1st sub-server in it''s list. The client then tries to connect to this sub-server. If this one is full as well, it keeps going to the next server in the list... Each sub-server just routes commands back and forth between the main server and the client. The nice thing about this is that you can run subservers on different ports or different machines. The main problem is all the extra handshaking (ie. having pseudo socket handles/structures and routing). Is there a better way? I find this solution very scalable if all the servers are run from the same LAN. Any thoughts?

That''s what I''m going to be doing except the server''s are completely clueless that there''s a lobby clients connect to before them.

Basically the lobby will connect to each server in it''s list every several seconds and grab it''s current number of players. Then when a client connects to the lobby it sends the IP and port of the first open server. That way the server doesn''t have to keep track of sub servers and clients can connect directly to a server if the lobby goes down.

It also allows me to work on the lobby seperatly of the game server itself. I''ll also only have one database of servers to keep track of. 1000 connections is going to be plenty for quite a while.

Ben



IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting ]

You shouldn''t wait until a server is ''full'' to redirect connections to another server. Do some reading on ''load balancing''. It is actually a very serious research topic.

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

UDP is the better way you seek... Not to incite yet another holy war, but when dealing with large connection counts, UDP is a far better method. The system only has to maintain one socket. You can code your own logical connections for reliability. It''s not entirely trivial, but it''s certainly something that anyone considering a multiplayer game should be capable of.

Good luck.

>>UDP is the better way you seek...<<

Do you know of any books/links/etc on getting into UDP?

>>The system only has to maintain one socket.<<

Sounds tasty!

UDP is nice and all, but I don''t want to reinvent the wheel. And I need to use SSL and I haven''t seen any docs with OpenSSL that''ll let you do that (I might be wrong). Also, UDP doesn''t work to well with proxy servers unless you''re the admin and can set it up yourself. But most users won''t have a clue about that, so UDP is ultimately not even close to being an option, even though I''d love to use it.

Load balancing is something I don''t really have to worry about. One machine can easily handle several thousand connections. In my case, there won''t be much data going back and forth. But I''ll keep it in mind for other projects.

I do like the idea of telling the client which server is open, instead of trying them all. Pretty obvious. (DOH!!! Shoulda thought of that.) I''m too far in to have a lobby though. Maybe the next revision. Great idea. I don''t think there''ll be that many players in my game that it''ll cause any problems without it though.

Teknofreek - Try the book "Advanced 3D Game Programming with DirectX". It has a great introduction to reliable UDP.

Vorlath - There are a variety of user levels that frequent the boards here,so if you already understand the following please don''t be offended...

Using UDP isn''t about reinventing the wheel at all. It is a necessary fact when dealing with large numbers of network connections. There are inherent latencies in TCP that will cause you to lag significantly when processing large numbers of connections. Consider that an average TCP socket can have inherent delays of up to 200 ms (or more!), not to mention the inherent lag of routers/Internet traffic, and the processing time of your game logic.

Yes, you can use TCP, and for a couple hundred connections the inherent latencies might be tolerable. Most MUDs use TCP, and begin to lag horribly over 200 connections. You will notice short "bursts" of activity from time to time... If that is acceptable, then TCP it is. Otherwise, UDP is always a better option. Most firewalls and NATs will allow users to initiate outward-bound contact to a server. Maintain a keep-alive scheme that will cause the NAT to maintain its address mapping.

Now, the SSL issue changes things a little... If you HAVE to use SSL, then you are stuck. If you just need some encryption, then look for something less bulky. SSL isn''t the fastest thing around, nor is it the most secure (although it is pretty good all around). No, SSL doesn''t have a UDP mechanism. But if you use SSL for authentication you can establish connection via SSL, authenticate, then hand the user over to a UDP connection. It''s done this way quite often...

Anyways, I wish you luck in your endeavor. Is it specifically for a game, or some other mainstream type of app?

Are you programming a game? It doesn''t really sound like you''re making a game, primarily because of what you''re talking about... very little information, must be TCP and SSL (isn''t SSL by definition port 443?).

I can see very little information per packet, but I can also see a lot of packets going out for just about any game.

As for UDP, I''m sure that there is some reason why Id, Epic, Blizzard and just about every other company out there is using it and not having to reconfigure any routers. I just have a cheap Linksys router, have done no configuration (well, beyond my DMZ host) and have no problem playing Diablo2 or UT through my router. In other words, they can do it, so can you.

SSL is just an encryption layer for any sort of TCP connection. IIRC 443 is the port used by https, i.e. http over SSL.

And yes, outgoing UDP connections will always work, even behind a NAT router (otherwise, even a simple DNS query would fail...). If you want to host a server from behind a NAT router, you''ll have to setup port forwarding on the server, but you have to do that with TCP as well. If your subnet is using global IP addresses you won''t have to worry about anything at all.

cu,
Prefect

Return to the Shadows

>>Teknofreek - Try the book "Advanced 3D Game Programming with DirectX". It has a great introduction to reliable UDP.<<


Thanks a lot fingh...I''ll check it out