heya all,
Last thing I heard was there was someone new looking into spidermonkey. So I thought I’d just post my question here.
I have been using spidermonkey for quite some time now, without much problems. However, after the latest changes I can send messages from my client, but they are not received on the server.
I can see that my client is sending the messages, the client.send method is called ok. But the messages are not received on the server. What I can see is the client connected event.
If anyone has any idea what caused this problem, I’d be very happy.
Mark
Have you converted to the new API (as in the doc normen linked) or are you still using the com.jme3.network.connection stuff?
Ok, so I started changin over to the new API. But how do I set it up to send via upd / tcp, secure / unsecure? and how do I detect if a HostedConnection is either UDP or TCP?
BTW, I asked the question about conversion because it would help debug the problem… not necessarily to push conversion though ultimately that’s probably better. The older code has a tendency to fail to send out queued messages sometimes.
To hopefully answer your questions:
HostConnection is not TCP or UDP… if UDP is on then it is both. You are supposed to be able to tell from the message but I haven’t fixed the reliable flag yet. This is something I intend to do anyway but if you have a specific use-case in mind for why this is useful then that might help make sure we do it right.
And that reliable flag is how you send one versus the other… just like the old API, setReliable(false) will send over UDP if it’s available. Unlike the old API, if for some reason the connections don’t have UDP setup (you’d have to manually instantiate the stack to get this) then the message will be sent over TCP even if it’s marked unreliable.
re: secure / unsecure
Did old spider monkey support secure sockets? I know it had a connection implementation for SSL but it looked unfinished when I looked at it.
To be honest, I really didn’t know how many people were effectively using Spider Monkey and what features they were able to get to work for them. So this sort of feedback is useful. When I tried to use the older code, I had numerous fundamental and basic problems just getting some things to work at all… so I wasn’t sure how widespread usage was of some features.
The newer core hopefully makes a much better foundation to move things forward, though.
With the old spidermonkey, you were able to tell if a connection was UDP or TCP because then it would be either a UDPConnection or a TCPConnection (both subclasses of Connection) I used this to be able to determine how to send back a message. If it was sent to the server via UDP, I would then send the result also via UDP. I’ll just send everything TCP for now, although I will continue to register both TCP and UDP ports.
As for the SSL connection, I know it was planned, so I set the variable on the Message. Never did anything though as far as I know.
In the end I mainly used standard TCP since all OGF is when it comes down to it is a sort of pumped up chat server with some extra features geared towards multiplayer gaming.
Oh, and now that’ we’re talking about doing things slightly different in the new API… Could you figure out a way to get rid of the id I have to supply to the serializer when I register my own message classes? This whole id business is hard on the maintenance and the administration.
Ultimately, the Message.isRelable() flag will tell you how a message was received and you can use that to send a message with similar reliability back out again. If I think of it when I get back to the code, I’ll fix it tonight.
Old SpiderMonkey didn’t really pay close attention to threading. This created problems for users and it created problems for SpiderMonkey. The new version has a tight and very specific thread design. By the time the message gets to HostedConnection, it is fairly far removed from the actual connection that it came in on and this reliable flag would be the only way to tell.
Another aspect of the new threading model is that your message listener may get called by more than one thread at a time depending on the underlying server implementation. The server enforces only that for a given HostedConnection, the message listener will not be called at the same time.
The serialization stuff makes me uncomfortable. You actually don’t have to specify an ID for your class as one will be assigned when you register it with Serializer. The issue is that if you register your classes without an ID then you must do it in Exactly the same order on client and server or you get all messed up… because as far as I can tell, classes are assigned IDs as they are registered. There are different solutions to this problem but they all have their own ugly trade offs.
I think the current spitballing is that we’ll create a ‘compile’ step that is invoked automatically during client/server negotiation and assigns IDs in a consistent manner… as long as all relevant classes are at least registered. It just means that attempting to register a class without an ID after the compile() step will throw an exception… but users that hit that exception were going to encounter problems anyway. The compile() step would also let us compare a hash of the client’s and server’s lists to help make sure they are compatible.
The most flexible solution is to let everyone define classes in whatever order they want and then somehow negotiate a mapping on the server such that class IDs can be mapped per client. The (perhaps significant) downside of this is that broadcast messages have to be serialized once per client.
It is on my to-do list to make all of that more flexible.
Use of Message.isReliable() to indicate transport is now fixed in SVN. If a message comes in on UDP then isReliable() will return false.
Cool, I’ll be able to test that tomorrow then, once it hits the nightly build.
I got my maven setup with an ant task which downloads the nightly build and installs the jars into my local repo. Works great…
With respect to registering the classes with the serializer, I find that the best way to do this and make sure you don’t forget anything is have a seperate jar containing all the messages and a base spidermonkey class which is extended on both the server and the client. This class then has a method which registers all the classes. That way you are 100% sure you have the same classes registered on both the server and the client. It also ensures they are registered in the same order.
Yeah, that reason I find that so distasteful is that it makes it hard to have add-on services that register their own internal-use messages. For example, if we added some kind of chat module and a physics sync module, etc. then the user would not only need to register their own messages in order but also make sure to touch each of those modules in the same order on both client and server. We either expose all messages and make them do it manually or give them specific IDs and hope there aren’t collisions with the user’s classes.
I’d like to remove “order” as one of the things that must be right.
Yeah, just have the server determine the order, and then on the connect of a client, the server returns the list of classes / ids
Then the client can set the ids to be the same as the server. Just have that for a sort of connect handshake.
…which still implies some sort of compile() step after which registrations will blow up. 
I’m taking one step at a time.
not necesarily. The only problem is message which are registered AFTER a client connect. But you could just send updates to the client for this without to much trouble. Would consume some bandwidth off course, but how often would this be needed?
That way, the server would always be leading, and could just uses some sort of auto incrementing int (or long) to keep track of the ids.
oh, and btw. If you could add me to your msn we could more easily talk about this stuff…
and I may even be able to help out code wise from time to time.
ractoc said:
not necesarily. The only problem is message which are registered AFTER a client connect. But you could just send updates to the client for this without to much trouble. Would consume some bandwidth off course, but how often would this be needed?
That way, the server would always be leading, and could just uses some sort of auto incrementing int (or long) to keep track of the ids.
The issue there is that the serializer code would have to be aware of the networking code. That would be a shame as the separation is pretty nice otherwise.
The alternative would be to make users register all of their classes with the networking code... which is also similarly distasteful.
Not sure what you mean about MSN since I don't use it.
Ah ok, any other instant messenger?
Cause I seem to be one of the more active users of spidermonkey and I used to test / debug / code fix for Lars as well, so might as well keep doing that with the new version. And for that, a direct line would work best.
ractoc said:If you have Gmail/Jabber I'll invite you to the team chat.
Ah ok, any other instant messenger?
Cause I seem to be one of the more active users of spidermonkey and I used to test / debug / code fix for Lars as well, so might as well keep doing that with the new version. And for that, a direct line would work best.
Yeah I have GMail, should even have a Jabber account somewhere. No idea what it was though, so may end up getting a new one if needed. Can you give me a Jabber server to register with?
Alright. Details sent.
and gmail address returned…