Is there anyone who has used the Java Kryonet library in a project willing to share their experience? I've seen it recommended a few times, but haven't actually seen anybody talk about their experiences using it.
Specifically, I want to make sure that it is reliable and relatively stable. Or should I consider using something like Google protocol buffers with custom networking code?
Thanks!
I have discussed the kryonet and kryo in my master's thesis and compared it some of the contemporaries; that should give some information and analysis about Kryo: http://de.scribd.com/doc/67084961/MasterArbeit
Answering the other half of your question that isn't addressed by the older one, Protocol Buffers have the advantage of being much more widely deployed, so you're less likely to run into major bugs. There are serious downsides, though, not least the facts that (1) you have to define your format using an IDL and then use PB's generated classes (meaning you may have to copy data in and out of your own back-end objects, which might result in lower performance) and (2) PB doesn't support polymorphism except through a variety of difficult-to-manage hacks.
So, if you're just looking for a straightforward way of transferring structured (but not object-oriented) data from one endpoint to another, Protocol Buffers is probably your best bet. More complex scenarios probably favour Kryonet.
HTH
I developed a game with kryonet and it works like a charm. It is also very easy to use.
I am currently working with Kryonet and making a game. I have myself found it as a very helpful and easy to use library. It has a very simple API which makes life very easy. I won't say it is as powerful as something like Netty or Apache Mina but it does all the required tasks. I personally love it and I will use it everywhere I can unless I require something more powerful or sending huge data as other libraries provide much more than KryoNet when it comes to sending data.
Related
I'm currently considering using java in one of my projects(for reasons unrelated to networking). At the moment I'm using C++ and a custom protocol built on top of UDP. My problem here is that while the added efficiency is nice for sending large amounts of realtime-data, I'd rather have something along the lines of RPCs for pure "logic actions" such as login. RPC's in C++ are hard to do though, since standard C++ itself has no notion of serialization.
In another answer, I found Java's RMI, which seems to be similar to RPCs, but I couldn't find how efficient/responsive it is, nor whether it could be plugged into my existing UDP socket, since I don't want to have two ports open on my server program.
Alternatively, since I think Java has serialization, I could implement RPC's myself, depending on how straightforward deserializing an arbitrary stream of objects in java is. Still, if this would require me to spend days on learning the intrinsics of java, this wouldn't be an option for me.
If you're interested in RPC, there is always XML-RPC and JSON-RPC, both of which have free/open-source C++ implementations. Unfortunately, most of my development has been in Java, so I can't speak to how usable or effective they are, but it might be something to look into since it sounds like you have already done some work in C++ and are comfortable with it. They also have Java implementations, so you might even be able to support both Java and C++ applications with XML-RPC or JSON-RPC, if you want to go down that route.
The only downside is that it looks like most of these use HTTP connections. One of the things you wanted to do was to reuse the existing connection. Now, I haven't looked at all of the implementations, but the two that I looked at might not meet that requirement. Worst case is that perhaps you can get some ideas. Best case if that there might be another implementation out there somewhere that does what you need and you now have a starting point to find it.
The use of RPCs as an abstraction do not preclude the use of UDP as the transport layer: RMI is an RPC abstraction that generally used TCP under the hood (last time I looked).
I'd suggest just coding up a Java layer to talk your UDP protocol: you can use any one of many libraries to do it and you don't have to discard all your existing work. If you want to wrap an RPC layer around your protocol no reason why you can't do that: create a login method that sends the login UDP packet and receives the appropriate response and returns it.
If it's a remotely serious project, you should probably take a look at Netty.
It's a great library for developing networked systems, has a lot of proven production usage and is well suited for things like TCP or UDP client-server communication. I wouldn't go reinventing this wheel unless you really have to :-)
As a bonus they have some good examples and documentation too.
We have two code bases, one written in C++ (MS VS 6) and another in Java (JDK 6).
Looking for creative ways to make the two talk to each other.
More Details:
Both applications are GUI applications.
Major rewrites or translations are not an option.
Communications needs to be two-way.
Try to avoid anything involving writing files to disk.
So far the options considered are:
zero MG
RPC
CORBA
JNI
Compiling Java to native code, and then linking
Essentially, apart from the last item, this boils down to a choice between various ways to achieve interprocess communication between a Java application and a C++ application. Still open to other creative suggestions!
If you have attempted this, or something similar before please chime in with your suggestions, lessons learnt, pitfalls to avoid, etc.
Someone will no doubt point out shortly, that there is no one correct answer to this question. I thought I would tap on the collective expertise of the SO community anyway, and hope to get many excellent answers.
Well, it depends on how tightly integrated you want these applications to be and how you see them evolving in the future. If you just want to communicate data between the two of them (e.g. you want one to be able to open a file written by the other, or read a stream directly from the other), then I would say that protocol buffers are your best bet. If you want the window rendered by one of these GUI apps to actually be embedded in a panel of the other GUI app, then you probably want to use the JNI approach. With the JNI approach, you can use SWIG to automate a great deal of it, though it is dangerously magical and comes with a number of caveats (e.g. it doesn't do so well with function overloading).
I strongly recommend against CORBA, RMI, and similarly remote-procedure-call implementations, mostly because, in my experience, they tend to be very heavy-weight and consume a lot of resources. If you do want something similar to RMI, I would recommend something lighter weight where you pass messages, but not actual objects (as is the case with RMI). For example, you could use protocol buffers as your message format, and then simply serialize these back and forth across normal sockets.
Kit Ho mentioned XML or JSON, but protocol buffers are significantly more efficient than either of those formats and also have notions of backwards-compatibility built directly into the definition language.
Use Jacob ( http://sourceforge.net/projects/jacob-project ), JCom ( http://sourceforge.net/projects/jcom ), or j-Interop ( http://j-interop.org ) and use COM for communication.
Since you're using Windows, I'd suggest using DDE (Dynamic Data Exchange). There's a Java library available from Java Parts.
Dont' know how much data and what type of data you wanna transfer and communicate.
But to simplify the way, I suggest using XML or Json based on HTTP protocol.
Since there are lots of library for both applications and you won't spend too much effort to implement and understand.
More, if you have additional applications to talk with, it is not hard since both tech. are cross-languages.
correct me if i am wrong
Which is the overall best option for calling Java from PHP?
Gearman
PHP/Java Bridge
or something else entirely? By "best" I mean easy to use, reliable, transparent (for debugging purposes) - the whole enchilada.
To put it the other way, does either solution have any major shortcomings?
Edit: the reason for this is a PHP site which needs to use a 3rd party SOAP service. The type hierarchy defined in the WSDL appears to be too complex for any pure PHP client.
The PHP/Java bridge is functional, but we found that it tended to leave around zombie JVM processes as Apache children that have to be kill -9'd to get rid of. We ended up running a cron job daily to take care of the problem. We only used it for one specific class (an interface class to someone's horrid SOAP endpoint), and it was a tad bit finicky when it came to type juggling, but it did work for us. (The zombie process problem may have been due to the prehistoric PHP version we were using at the time, so it may have been fixed by now.)
I don't have any experience with Gearman and Java, but plenty of it with PHP. It's been a pleasure to work with, for the most part. The most annoying issue is that processing async updates from the caller requires some pretty verbose code to handle all of the possible states. For fire-and-forget and fire-and-get-back-immediate-results RPC, though, it's really hard to beat.
Gearman is probably not really the solution you are after (unless you really want a job queue rather than some form of RPC). It can operate in a blocking/synchronous fashion but it brings alot of overhead (code/application/etc wise) to the party for what i'm guessing is a simple task?
Without knowing what you are trying to do i'm going to throw some suggestion out there. XML-RPC (can be slightly less evil than SOAP!) or maybe something like Facebook's Thrift[1], Apache Avro[2], or Google Protocol Buffers[3]?
[1] http://incubator.apache.org/thrift/
[2] http://avro.apache.org/
[3] http://code.google.com/apis/protocolbuffers/
I'm developing a Java Based server, with NIO multiplex and I started to see a lot of frameworks... I don't understand if these frameworks makes the life easier only or has also an increment of performance ( for example netty )
No framework can increase performance of what's underneath it. In the case of NIO I've come around to the view that it already is a framework itself. I've reviewed a couple of NIO frameworks such as Mina, and indeed wrote one myself, but my own conclusion is that this is largely wasted effort, that ultimately gets in the way one way or another. All you need is a well-written select loop and the appropriate data structures.
I think the core point is that they make life easier/get you productive faster. They may be more or less performant compared to each other, or to your own code (no reason to think that if you coded it from scratch you would get better performance the first try - of course ultimately you own it so you can optimize it to death if you want and have the time).
Ultimately they are all using the Java NIO framework and classes, and the only way to outperform those is to do your own JNI - assuming you succeeded - it is hard stuff, really a specialty of its own within programming.
It depends on what you're trying to do. NIO frameworks are useful because they provide you an abstraction of NIO core action. Although, they force you to use several design patterns you may not be comfortable with.
If you think you adapt yourself to those design patterns you should probably use a framework. It will have less bugs, you will have less work to do and ultimately you won't see where all of the action happens. You just have to focus on what you are trying to achieve.
It has some additional overhead in comparison to a "domestic" solution but it is negligible.
It really depends on your level of knowledge with the java.nio API. If you're not sure on how things work then you should probably use a 3rd party API. If you know how things work and are capable of writing code without a 3rd party API then you should definitely use your own code without any strings attached. You can achieve better performance without extra things (3rd party API) going on.
I like to live by the KISS principle.
I have a java back-end that needs to expose services to clients running in the following environments :
J2ME
Windows Mobile
iPhone
I am looking for the best tool for each platform.
I do not search a technology that works everywhere.
I need something "light" adapted to low speed internet access.
Right now I am using SOAP. It is verbose and not easy to parse on the mobile. The problem is that I have not seen any real alternative.
Is there a format that works "out of the box" with one of these platforms ?
I would rather not use a bloated library that will increase tremendously the download time of the application.
Everybody seems to agree on JSON. Does anyone has implemented a solution based on JSON running with Objective-C, J2ME, Windows Mobile ?
Note : so far the best solution seems to be Hessian. It works well on Windows Mobile and Objective-C/iPhone . The big problem is J2ME. The J2ME implementation of Hessian has serious limitations. It does not support complex objects. I had written another question about it.
If you have any ideas, there are very welcome.
JSON is fairly compact, and supported by most frameworks. You can transfer data over HTTP using standard REST techniques.
There are JSON libraries for Java, Objective C, and many other languages (scroll down). You should have no problem finding framework support on the server side, because JSON is used for web applications.
Older alternatives include plain XML and XML-RPC (like SOAP, but much simpler, and with libraries for most languages).
Hessian. http://hessian.caucho.com. Implementations in multiple languages (including ObjC), super light weight, and doesn't require reliance on dom/xml parsers for translation from wire to object models. Once we found Hessian, we forgot we ever knew XML.
REST + XML or JSON would be a good alternative. It is making big strides in the RIA world and the beauty of it is in it's simplicity. It is very easy to use without needing any special tooling. SOAP has it's strong points, but it works best in an environment with strong tooling support for it. I'm guessing from your question that's not the case.
Seconding JSON. I ported the Stringtree JSON reader to J2ME. It's a single class JSON reader that compiles into a 5KB class file, and directly maps the JSON structure into native CLDC types like Hashtable and Vector. Now I can use the same server for both my desktop browser AJAX frontend and my J2ME client.
How about plain old XML (somewhat unfortunately referred to as POX)?
Another very useful option would be JSON. There are libraries for every single programming language out there.
Possibly, since you are working in an environment that is constrained in terms of both computing and networking resources, and with a statically typed language, Google’s protocol buffers would be preferrable for you. (Just disregard the RPC crud in there; RPC is an attractive nuisance, not a useful technology.)
The problem with your question is that you haven’t provided a whole lot of context about what kind of data this is and what your use cases are, so it’s hard to speak in anything but very vague generalities.