Few design issues

Hi Ive been writing a server and client for awhile now and all is well on the testing front I just need to clarify a few assumptions I have from previous networking systems to move forward



My idea was to have a server broadcasting advertisements, a client comes online starts receiving these advertisements and fills in a table with the available servers. The player can then selects the one they want to join and connect specifically to that server ignoring the rest



So does the broadcast function actually broadcast anything and by this i mean the actual networking definition of a broadcast which is sent to all connected machines on the same subnet / ip address range? or does it only send to already connected clients? and if not is there any way to achieve the same effect? can i somehow send a directed message to an ip address then just loop through all the addresses in the ip range that the server is part of?



second is it possible to create a client that doesn’t already know the server address? something that can sit on the network and wait to receive the above broadcasts from a server?



Basically I want a server and client setup that is automatic that just works on a network i don’t want users having to know or type in specific ip addresses unless absolutely necessary.



I recently tried creating a ServerListener class to listen for broadcasts and then establish a client connection to that broadcast address but this doesn’t work on a single machine as you cant use the same network address for two servers at once? this solution could still work as each machine will only have one game running on it in either server or client mode but its a pain for testing if i cant use the same machine anymore heh and it only works if broadcasting is real as well

Code:
Caused by: java.net.BindException: Address already in use: bind

Thanks to anyone who can clear some of these questions up :)

Answering backwards:

“Address already in use” means you tried to start two servers using the same ports. TCP/IP doesn’t allow that.



What you are looking for is autodiscovery and really only works on LANs… and even then only if your network hasn’t disabled it. The typical way is to broadcast on a multicast address and pick up the datagram packets from that address. I’ve written many protocols like this in the past and they might work on a home network most of the time. I know that in corporate environments multicast only works about 25% of the time since many routers have multicast disabled by default.



SpiderMonkey does not include such autodiscovery… partially for philosophical reasons and partially for “bang for the buck”. It’s non-trivial to implement properly and is almost never useful. Most online games now tend to be over the internet, after all. In those cases where you have your friends over to your house, it might be a little convenient but if you are on a DHCP network then you can just use your host names and not worry about IP addresses anyway. And multicast is one more thing in a series of things that can go wrong. “I can ping the other machine but it won’t f***ing find it?!?” Between getting firewalls opened properly, etc. it’s better to have a few concrete things.



And multicast/autodiscovery problems are almost impossible to debug… especially via the forum. At least with direct connects, there are some very specific trouble-shooting steps.



Philosophically, I’d rather incorporate a game matching service of some kind… or the pluggable ability to add one. So instead of auto-discovery, you can ask some API to check for available servers. It may use auto discovery under the covers or may hit a remote web site to download the latest server list, etc… I’m interested in doing that but I haven’t gotten around to it yet. I will prototype it for Mythruna in the next few months, probably… and then we can see if it’s just a contribution or something that gets added right to SpiderMonkey as an API extension.

Thanks for the reply pspeed,



My game is specifically lan based at the moment because i don’t want to have to host a perm server out in the www for this game at least not yet, during development it is much easier to use autodiscovery as well as after release, just pinging an external server is relatively trivial but it does assume that you have internet access and cripples the game without it otherwise i need to develop another app that is just a server and allow people to download and install it and even that isn’t a fantastic solution, still means everyone has to type in a server address which is replicating the work that shouldn’t have to be done in the first place.



Auto populating servers in a lan environment is a typical hallmark of any decent multiplayer game from the last 12 years or so i could easily name 10-20 mainstream games that have this feature. I do attend lans and the games that don’t support autodiscovery are always the ones that have issues connecting. Its only in the last few years that games have moved away from this model and it seems to me that this is mostly from copyrighting and advertising issues not wanting ppl to be able to play it without some kind of monitoring(Login systems) hence the movement of not allowing lan play specifically has come from the big game cooperation’s like steam, activision and blizzard perhaps part of it also is more ppl are connected to the internet with better connections these days but my game is designed for lan play first and internet play second



Using hostnames is just as troublesome as using ip addresses it still requires multiple steps checking what your hostname is loading the game remembering the obscure phrases that your friends use for their computers manually specifying it its irritating in a lan environment when such things are so easy to code



I personally think broadcasting is much easier to debug and to use then directed connections on most user environments it doesn’t require any configuration it would have to be a weird setup that has someone trying to connect within a lan with a router in between two computers and in that instance i think it would still allow multicast packets except on the external side so long as they are in the same subnet not to mention you can use any host of free and commercial tools to watch the packets and debug if they are being sent or not and whether they are getting to the destination as well.

Even if there are issues that is on the implementation side whether it does use the actual multicast address or manually send messages to all computers in range even possibly taking an address range as an argument to “Multicast” to. also could use directed connections to debug multicasting ones if multicast doesn’t get through but directed did then its an issue with the mutlicast protocol at router or pc side



Anyway more to the point heh

The end goal i am trying to get to is autodiscovery yes but I’m not expecting spidermonkey to do all the work for me

All I need is to be able to create a listening client everything else is workable with other solutions



It seems your saying this isn’t possible yet so I will keep using the solution I have already coded and make up a virtual machine to run the client or server on so they can both use the same port and have to modify the broadcast method on the server to actually broadcast now heh



It is possible to send a message to an ip address right? without having a preexisting connection? is there any examples of this?



Thanks for replying so quickly and comprehensively :slight_smile:

You can send whatever messages outside of SpiderMonkey doing your own networking that you want to. Usually with autodiscovery you have the server listen to a multicast address and then joining clients will send out a broadcast (to that address) every few seconds until the server sends a “here I am” message. That message could contain the host information for connecting using traditional spider monkey methods.



The issue with trouble shooting multicast problems (and even switches can have this disabled… anything with its own ARP table basically… and what network isn’t switched these days? :))… is that when something goes wrong, you have no idea which of 20 different things it could be. The machines are playing marco polo and they might not even be in the same pool.



With direct connections you get “connection refused” or a timeout trying to fix up all of the ports. Both of these things have a specific set of steps to resolve: “Can you see the other machine from Windows?” “Can you ping the other machine?” “Is it’s firewall active?”



Also, I’ll point out that you don’t need a central server to play on the internet though you do need to know the host to connect to and that host needs to forward ports (generally). But if SpiderMonkey ever provides a matching service the idea would be that maybe jme.org could host a list by default or something. This has only been vaguely discussed.



The reason I think that internet play is stressed over lan play is because it’s “fast enough” and if you write it to work on the internet then it will also work on a LAN. From personal experience, that last time I tried to get a LAN party together (which was more than 8 years ago now) most of my friends were like “Can’t we just do it over the internet and save me the trip?” Lame. :slight_smile:



Implementing self-discovery on your own shouldn’t be very hard (sounds like you may already have it). You could still use spider monkey for the actual game play, though. Most of the time the messaging used for autodiscovery is completely separate anyway. It definitely has nothing to do with the core spider monkey messaging kernel.