A server has a game version and game name property. Each client expects to communicate with a server with a certain game name and version. Test first whether the game name matches, and then whether game version matches, before sending any messages! If they do not match, SpiderMoney will reject it for you, you have no choice in the mater. This is so the client and server can avoid miscommunication.
I found only this in the doc for the Server-Connection.
Is there a way to check in the client if the Server has the right Game-ID?
Something like a exception or a Code maybe?
You can’t connect to a server that says it has a different protocol version because no messages will be able to pass… because the protocol is different.
Yeah, thanks for the javadoc-Links. I hadn’t found them yet via the wiki…
If anybodys wondering how to set game name, id and so on:
define it while creating the server:
Network.createServer(String gameName, int version, int tcpPort, int udpPort)
throws IOException
Well, I didn’t had a StateListener, yet, but I will have to add it now - because otherwise the programm don’t react at all if I put in a wrong ID. Maybe a Listener will solve this problem.
[UPDATE:] I added a ClientStateListener. But the Problem with the programm halt continues. Here is some Code I tried:
for the client:
(The isReady-Function returns 1 if connected have been called)
try {
client=Network.connectToServer("MyGame",1, ip, port);
//return "test"; // this output don't appear if it's the wrong IP
ClientStateListener CSL = new Cl_StateListener();
client.addClientStateListener(CSL);
Cl_StateListener ClSL = (Cl_StateListener)CSL;
if (ClSL.isReady()==1){ //this don't work...
client.start();
// and some other actions if the connection is sucessfull
return "connected";
}
return "not yet connected";
}
catch (IOException) {
return "wrong input";
}
catch (ConnectException) {
return "Can't connect";
}
The other problem occurs now, that i got evertime a ConnectException, if i want to connect to my localhost-Server that contains the correct Game-Name and Version. If I use the functions without this informations the Connection goes well.
Maybe I should try to handle an error-Listener… But for today it’s enough. Maybe you’d like to give me some advices for my rubbish code…
I have no idea what the above is doing but it definitely looks wrong. Your client won’t receive any events at all until you start it. But I’ve made a lot of assumptions reading it.
You have to have a ClientStateListener anyway as that’s the only way you can know when the connection is ready for sending without blocking.
ClSL is my implementation of a ClientStateListener.
It has a variable ready, which is set 1 if the Connection Event of the ClientStateListener is called.
The first line just transform the ClientStateListener in my class, so I can access the isReady-Function.
I moved the client.start-Function above this code, but nothing changed.
Well, the something else must be wrong in your code. Either the connection is giving an error that you aren’t seeing because you haven’t registered a listener or some other assumption is faulty.
…actually, even right after starting that if statement will never be true as it takes some time to setup the connection… thus the need for the listener to know when the connection is actually connected. So what’s wrong may not even really be wrong and only a perception issue on your part. Do some printlns in your connection listener.
Sorry, I have to agree with iova: wouldn’t it have been easier to let the connectToServer method block the thread and throwing an exception?
I have the similar problem as iova: i try to connect to the server, I implemented a ClientStateListener, but before I do not call start() of the client, the methods of the listener are never called?!
if you let connect be blocking, you cannot do background connection, as required for zoned mmo games for example.
But if you want it to be blocking, I suggest to take a look at a Semaphore object.
You can make almost any async call sync with it.
s = new Semaphore();
d = whatever
d.addListener(){
s.release()
}
d.startWhatEverAsync();
s.aquire();
the aquire will block till the release is called, (beware of shooting yourself with this if you misuse it however, you can easily create deadlocks with them)
if due to threading reasons release is called before accuire, it will just continue without blocking.
In general, it’s super-duper-pooper-scooper stupid for libraries to block for you. It’s a recipe for deadlock.
It’s always always always always always always always better to build things as asynchronously as possible… and SM tries to do that… and strongly encourages you to do that, too.
Trying to do it all in big swoop like you are means that you don’t care if the user thinks your application has locked up while it pauses all rendering for 30 seconds as it resolves the host name to IP, ferrets its way through the internet to find the actual server, and finally establishes a connection.
Because it’s such an incredibly bad practice to pause the whole application while one connects to a remote port, SpiderMonkey does not provide this option. You have to do extra work to do it the wrong way.