SpiderMonkey is a high performance Java networking engine. It is efficient, yet simple to use. Setting up a client/server mechanism requires no more than basic Java knowledge. The same goes for sending and receiving objects – in other words: Every monkey can use it!
I've done a lot of research on how to make SpiderMonkey better than already existing libraries, and with the following feature set I think I've succeeded:
UDP Done
TCP Done
SSL over TCP 70% done
Synchronization
Serialization Done
Voice chat Done
Chat (including channels, profanity filter (maybe), and completely extendable)
JDBC layer (maybe, more to come)
jME3 support layer
Android support
RMI 90% done
Compression Done
Connection filters Done
Streaming (files, data) Done
Easy to use, easy to learn
Generic enough to be used for just about anything
Thread safe
The code is going to be available under the BSD License, and can be viewed here. Repository url is jME3's :)
Let me know what you think! :)
Cool! I might suggest further adding a level of generic-ness and abstracting the jME3 layer to an 'asset' layer or something of the sorts. Similar for voice support; make the output an interface that you could just register a sound system with.
The rationale here is that you widen your user base if folks outside of jME3 are using it.. More bugs, patches, suggestions, etc
Thanks for the feedback!
Yes I'll definitely do that, thanks for the tip. It'll be generic enough to be usable for everyone :)
I'm currently working on a server / client system that will allow players to find eachother for multiplayer games. This library would need a lot of the features you are already planning to add to your library, so yours would be a good choice for me.
My system would be set up in such a way that is is useable as stand-alone, this could be used mainly for the chat functionality, or integrated in any game. I you'r willing, I would propose I use your network layer. That way, you can use my project as sort of a testing ground for your network layer. This in turn helps you figure out features that work, features that don't work and featuers that are still missing.
Today I've written the serialization system, and it turns out it's quite efficient. It uses 2 bytes for a class ID (compared to 4 bytes for some other serialization engines I've never heard about), and of course the serialization system is extendable. Class registration is forced, so no class names that are being serialized and sent across the network.
I've updated the first post with status updates next to the features. I'll keep you updated!
Another update; almost done with the TCP and UDP connectivity, just need to try some things out and add some extra utility methods. Serialization has changed a bit, but it should remain like it is now for a while.
SSL over TCP has been dropped, to replace it I will be implementing an encryption system, which'll allow encrypted messages over the already existing TCP/UDP connection. This means that you do not need a separate SSL connection any longer.
File streaming has been added to the feature list - it does exactly what you think it does. Also works over the already existing TCP/UDP connection (though you'll probably want to use TCP for this).
I'm curious as to the decision to drop the SSL connection…
Once the initial handshake is done there's minimal overhead required… It might be something that you want to maintain for certain requests while others go over standard TCP. What it sounds like to me is that you'd have to encrypt every message (and then decrypt it eventually)… wouldn't that be a potential choke point?
I'm curious as to the decision to drop the SSL connection..
Once the initial handshake is done there's minimal overhead required.. It might be something that you want to maintain for certain requests while others go over standard TCP. What it sounds like to me is that you'd have to encrypt every message (and then decrypt it eventually)... wouldn't that be a potential choke point?
Edit: Forgot to mention the other stuff:
Sounds great!
I'm uncertain what you mean, to successfully create and run an SSL server, you would have to run it on a separate connection. So this means that you have a separate connection while you may not even have this extra connection, this extra port, this extra processing power required. It could replace the TCP server as a whole though, but that means that all objects, if they need to be encrypted or not, are going to be sent across TCP with SSL. For objects that don't need to be encrypted, that is lost processing power right there. SSL decrypts messages internally, just like SpiderMonkey will do by itself (as the planned 'custom encryption' feature).
Thanks for the feedback, let me know if that's what you meant :)
True, having to open an extra port could be annoying. My point was basically that some things could be sent encrypted (and others not) concurrently. Its true you're still a slave to bandwidth and latency however
Definitely intriguing, doing everything over the same connection… I'm still having some trouble understanding how it will work (one handshake at the beginning?) but you haven't told us that part yet! Looking forward to the surprise!
Just saw that a JDBC layer is a maybe. Let me know if I can be of any help, I've gotten to know the sweet and the sours of JDBC over the past few years.
True, having to open an extra port could be annoying. My point was basically that some things could be sent encrypted (and others not) concurrently. Its true you're still a slave to bandwidth and latency however :)
Definitely intriguing, doing everything over the same connection.. I'm still having some trouble understanding how it will work (one handshake at the beginning?) but you haven't told us that part yet! Looking forward to the surprise!
Just saw that a JDBC layer is a maybe. Let me know if I can be of any help, I've gotten to know the sweet and the sours of JDBC over the past few years.
Nothing set in stone yet, haven't really given this a thorough thought yet, but I thought just handshaking whenever one peer wants to enable encryption. The keys would probably be cached there for any later encryption that needs to be done.
Quote:
Consider that SSL probably won't work under UDP, which is used by most games.
Yeah, SSL over UDP is quite..useless.
Quote:
By the way Levia, how are you going to establish the certificate authority? It won't work without a central server.
You can probably use "fake" encryption using RC4, but you still need to send the session key initially.
I don't really understand this - since SSL isn't going to be used (for now, atleast) why do we need a CA?
By the way Levia, how are you going to establish the certificate authority? It won't work without a central server.
You can probably use "fake" encryption using RC4, but you still need to send the session key initially.
I don't really understand this - since SSL isn't going to be used (for now, atleast) why do we need a CA?
You can't have public key security without a certificate authority, since you would have to send the public keys between clients. A MitM attacker could listen and modify packets, if he arrived when the channel was being established.
In other words, you can't have two clients communicate securely if they don't know anything about each over.
Momoko_Fan said: You can't have public key security without a certificate authority, since you would have to send the public keys between clients. A MitM attacker could listen and modify packets, if he arrived when the channel was being established.
In other words, you can't have two clients communicate securely if they don't know anything about each over.
This was one of my initial questions of how it would be implemented..
Levia said: Nothing set in stone yet, haven't really given this a thorough thought yet, but I thought just handshaking whenever one peer wants to enable encryption. The keys would probably be cached there for any later encryption that needs to be done.
Handshaking every time you want to send something encrypted means 5 legs for every secure transmission. Not only is it a waste of time in terms of the sensitive data being sent, but its also blocking any unencrypted communications since you're planning to go over the same link..
1 - the cost. If you want to do it right you'd have to go and buy an expensive certificate.
2 - you need a static IP address. Well you could do it with a dynamic one but then the costs would go up even higher.
Either you have to deal with those two issues, or setup your own trust server, which makes things way more complicated then you really want as well. I had somethings like this a while back with one of my applications. We took an entirely different approach: compiling on demand.
the process worked something like this:
1 - you go to the website and create an account.
2 - the system creates your account and with that account it creates an encryption key specific for your account.
3 - you login to your account on the website
4 - you press the download button.
5 - at this point, the system generates an encription.jar which contains all the encription stuff. This is done on the fly because your unique encription key is compiled into this jar.
6 - your download starts.
What this does is it creates an encription key that is linked to your login. Granted this has some problems as well, but for us it worked gret because for one the application was always installed on just one system at a time. So we could figure out which key to use that way. For your situation you could use something similar I guess but then this generated key would be the public key and you would use it to verify the client is who they say they are.
Oh and I put in one more thing to make things a little harder to hackers. Each time I sent an encripted packet from the server to the client, part of that packet was a new encription key. So the encription key is only ever valid for one exchange.
So a solution might be to setup SSL as well as some sort of enctiption over TCP.
with the latter using a less secure, but free form of encription.
Then you have a choice which one you use, the expensive high security solution, or the cheaper less secure solution.
Or, if all you're after for the cheap version is encription, you can just extend the classes that check the validity of the SSL certificate to always accept the certificate. Then you have the SSL encription, just not the client verification. This is a quick and dirty way of setting up an encripted connection that I've used before.
Alright, I really appreciate the responses guys, and as said I haven't thought about this part much yet so it's of course open for discussion. What do you guys think about Ractoc's idea - alteast provide SSL, but also a custom encryption method to go over one of the existing connections? How would you secure that?
Just another thought about the use of CA's… You don't have to go and buy one, but can use OpenSSL to your heart's desire… The fact is that if you're using WebStart (and I suspect the same is true for an Applet), you've already given the application access to your system by virtue of allowing the native libraries to run.
I think at the end of the day it comes down to what it is you're sending over the channel and how important it is to you. I wouldn't send anything with passwords over less than SSL because it seems like a violation of the end user's trust to me… Other things (like game statistics, sync data, etc) are less vital IMO.
The paradox that ractoc suggests is pretty on point though:
ractoc said: Then you have a choice which one you use, the expensive high security solution, or the cheaper less secure solution.
As I mentioned above, it doesn't necessarily have to be expensive (or intrusive to the user) if they've already given their system access to its resources..
Its easy enough to set up a secure socket in Java, I don't see any reason to not give users of the library the option. You can bet more than one person will ask for it as soon as they find its not there anyway I do think encryption of TCP is interesting though, and could be another tool in the arsenal!
I think the best way to implement SSL would be to simply ask for a keystore when setting up the socket on the server side and truststore for the client side. This way a developer could get away with no extra costs at all by just creating a self-signed cert on the server machine and distributing a trust store with the client package. As long as noone gets ahold of the private key (which can only be found in the keystore on the server machine), it should be fine. Not even a static IP should be needed.
Of course, if needed and the cost is not an issue, one could order a "proper" cert from a more official CA and supply that keystore/truststore when setting up the connection instead.
It should even be possible to let the server automatically generate a self-signed cert on initialization and then have the client automatically trust the first cert that the server presents after making a connection. This would open opportunities for MitM-attacks, but still not bad for completely automatic encryption.
Im an Instructional Designer and E-learning developer by trade and only just starting to get into the "Serious gaming" and virtual worlds development due in part to working on my Doctorate in Educational Technology and second I work for a major defense contractor and my current customer is the US Air Force, and they have a MAJOR bent on using "Serious Games" and gaming technologies for training, and are really pushing for this to be incorporated into web-based training/e-learning as well.
Virtually all military servers run off SSL if they are running a .mil domain, and by reverse DNS lookup if your coming from a .mil domain your are shuffled to an https SSL connection by default.
So, as someone else has stated, JME3/platform is being geared up for professional development, this includes Government and Military developers. Arbitrarily deciding to drop SSL/TCP is IMHO not a smart decision for the long term acceptance and utilization of this networking system - and OBTW, the military/Government has pretty deep pockets when it comes to investing in this type of technology. Due to security issues and "Mobile Code" restrictions in place, military users can't install plugins or proprietary players BUT they can run a properly signed .jar file via jnlp and Webstart option as a desktop application. That why there's a line quickly forming around JME3/Platform and anything involved with it.
So, by not including that as an option, you're basically shooting developers that support the Military/Government sector to develop serious games/simulation involving multi-user requirements in the foot before you even start. The Military has multi-layered CA with numerous options, so I have ample CA from which to choose, but I'm dead in the water if I can't use them at all because the option isn't there.
