This is probably a real simple questing. Currently, i have been looking into a way for the client to have a multitude of hardly used sockets instead of one big super-used socket. I already have the software design for how this is going to work, but on second thought, i would first like to know if it is acceptable. I will have a maximum of 5000 sockets on the server, and at one time the user may have as much as 100 to 150 sockets connected to various computers (possably interconnected like a distributed server network) with the differance being that the total bandwidth consumed for the user will (under most circumstances) remain under a 56k limit. Are the benifits im seeing in this not there? Is there any real PROBLEMS with my approch, is it going to kill the server, or will the large number of connections per client cause problems for the client?

If I understand you right, you''re wanting to store 100-150 sockets per client on a single server machine?! Firstly, the benefit of using multiple sockets is effectively zero. There''s no problem with it, but there''s no point convoluting and nearly neutering your code for it. It takes more memory, more time in loops checking each socket to see if it has data, that many more ACKs and packet orderings to ensure... you will essentially take away all the processing time from the actual client and chew it up polling a hundred sockets which aren''t doing jack.

You''re far better off with a single socket. There''s really no way a single socket will ever be insufficient, especially not if you can afford to cram your data down to 56kbps max.

No, not 150 per per client on the server, but 150 active on each client. (The server only makes 1 connection per client) The clients are essentialy making a peer to peer connection to eachother (communicating very little), and may have anywhere from 5 to 150 of these going at a time (it will under most circumstances stay under 50). The reason for this? distribute things that are not necessary for the server to handle, chat for instance.

And the clients are the ones im talking may be limited to 56kb, the server will not.

essentialy, i believe i have found ways to distribute things cutting nessessary bandwidth for the server (throwing it on the client) while still preventing things i dont want to happen from happening. (I have developed many designs for distributing a multiple things)

[edited by - paulcesar on June 20, 2003 5:06:36 PM]

is this acceptable?

quote:

---

Original post by PaulCesar
is this acceptable?

---

This model is inherently full of security problems. The fact that I know 100 other players'' IP addresses (and a potentially open port number in their firewall is a problem when it comes to a community based game with so many potential players.

I''m assuming one of the things you''ll be farming off is chat. This is perfectly fine until someone spoofs obscene messages to the 12 year-old kids playing your game.

Your client will have an awful lot of work to do tracking those 150 other clients. It just doesn''t seem like a good idea. Implement it, test it, let us know if it works reliably.

Ok, i plan on it. But yes, chat was the major thing i am farming off (using a map-sector concept to keep connections down). In a server with potentialy 2000 users, chat bears the brunt of the burden. While they could potentialy learn of the persons IP address, the port they will be using will be secure (chat will go client to client with very few commands other then start and block). But then again, if there computer is that insecure, they probably should not be surfing the internet should they? I am interested in your comment about the 12 year olds, as i dont see this posing a threat to the idea. A quick word censor inside of the client "should" take care of most of that. And above that, there is nothing to stop a 12 year old from being taught dirty language in any other large game is there? And as for monitoring someones chatting, it is not that hard to bug a person by placing (SERVERCHAT) in there IP chat sector (Lets me read what is being posted on the map) And person to person chat will be initialy disabled, and will require consent. This could also be expanded to include an out of game chat (similar) to MSN which lets you communicate with IN-GAME players (as well as people connected to the chat).
Other things were in the planning of being farmed off aswell. One idea i had was to have a person communicate his moves to all players in the sector (as well as to the server), the other players clients then check it to there map, if there is a problem, they make a report to the server (behind the scenes) and if it is faulty (ie on a wall) they get an updated position of the player (possable hacker''s) correct location. Whereas the person''s actual coordinates (yes, you dispatch to server), and any designated combat move is figured on server) a kind of peer to peer monitoring. This is one of the finer points of the system i have been developing, and tho i think it needs some work, i think i can keep server usage down to a minimum, WITHOUGHT being a major security bug. (by the way, the last bit about the movements i have not yet decided if i should use it, as it may actualy take MORE server and peer resources in the long run)

another question i have is, how slow would it be to automaticaly close and open ports when players leave or enter the given players sector (im estimating this may happen ever 2 seconds)

I''d go for the client chat model you have, however players sending their movement is a bad idea and it will cost more bandwidth problems in the long-run. Furthermore in any multiplayer game the server NEEDS to be the definitive source of info, and essentially what you''d do by having clients send their own movement data is add in a middle-man.

You may want to look into using UDP to send messages, perhaps you already are using it, but it should allow you to simply have one "chat socket" to handle all the peer-sent chat messages. granted, you''ll have to keep track of what came from who to have a whole message when its finally done, but it can be done this way. UDP sockets are connectionless and therefore you can send your message to different IPs via the same socket.

BTW, on the subject of UDP... you don''t say whether you''re using TCP or UDP, but if you are using TCP you need to stop what you''re doing and re-work it for UDP.

Ravyne
Owner/Lead Programmer & Designer
NYN Interactive Entertainment
HTTP://www.NYNInteractive.cjb.net

Yes, i am using a single UDP socket for handling chat. The person will still have to, nonetheless, connect to multitudes of other players. There will also be a single connection designated for a constent server connection.

In addition to chat, graphical representation of a person may be retrieved and sent from the person. Since this is going to have no impact whatsoever on the actual game play (graphical misrepresentation really is not a large concern) it will also be passed like chat (use same UDP or different?) This graphical representations will include player "sprite", as well as allowing each player to have a particular 64x64 icon (as well as guild icon). Possably more transmittions may be in the works in the way of "journals", but i cant give away everything can I....... . But nothing other then simple textural/pictoral data will be transfered from a user.