Can somebody please compare these two websocket servers. I have to select one of them; I need an expert opinion due to newbie in multiplayer "online" gaming. I would probably have the flash client. What challenges I could face using one over other.
thanks in advance.
Full disclosure: I work for Kaazing and I have not used jWebSocket myself.
A couple of quick points:
0) Production vs. Beta
Kaazing is production-quality software. The download link on the jWebSocket web page points me to a beta version of the product.
1) Client Technologies
Kaazing provides WebSocket libraries for multiple client technologies (JavaScript, Java, .NET/Silverlight, and Flash), It looks like jWebSocket provides JavaScript and Java. You mention you would need a Flash client and AFAIK only Kaazing provides that. jWebSocket uses Flash for emulation (see the next point).
Note: Kaazing now provides AngularJS, ReactJS, Objective-C (iOS), Xamarin (.NET with support for iOS and Android), Java, .NET, and Android clients. However support for SilverLight and Flash have been deprecated.
2) Emulation (for browsers that do not support WebSocket)
jWebSocket requires Flash, Kaazing does not.
Note that Flash emulation for secure WebSocket (wss://) requires you to open a separate port for the Flash x-domain policy file. In many enterprises this is a non-starter.
3) Protocol Support
Kaazing offers a wide range of higher-level protocols on top of WebSocket: JMS (can run against any back-end JMS message broker), STOMP, AMQP, XMPP, etc. I don't know what jWebSocket does in this space.
4) Enterprise Deployment
It is easy to configure the Kaazing WebSocket Gateway in conjunction with existing Directory services (LDAP). It supports Single Sign-On, and the gateway can easily be clustered for HA purposes (again, not quite sure what jWebSocket does here.)
Please take a look at the documentation for these features:
Security configuration:
Using the Gateway to Support High Availability
Secure Network Traffic with the Gateway
5) Open Source
jWebSocket is open source, Kaazing has both an open source Community Edition and an Enterprise Edition.
Hope this helps for now!
I am a jWebSocket developer, we are currently working in the first production version of jWebSocket, I will just mention some advantages of jWebSocket:
- Multiple clients ( JavaScript, C#, Java OS, BlackBerry, Android, GWT(In process), and some others ).
- Multiple WebSocket engines, just switch and run in the configuration, among them (Grizzly-GlassFish, Tomcat, TCP, NIO...) in order to become jWebSocket more widely used and make applications easier to be migrated.
- NFC and SmartCards, Arduino and other technologies.
- A very variated set of Demos in the client side (Games, Chat, sms, WebSocket-Captcha, Sencha, Jquery & jQuery Mobile plugIns, Arduino, Smartcard, SessionStorage, SSH-Remote Shell Control RT in the web, a Ping Pong Game demo, Channels to create full client side applications without need a server side plug-ins, etc... )
We have been working during a long time in a new Documentation, a new Web Site and a new Production release of jWebSocket for our community, jWebSocket is a project created by people from all the world who dedicate their free time to contribute and create a really usable product to be used by all the opensource community. We are trying to give our best to the community.
I wouldn't establish a comparison between Kaazing and jWebSocket, they both have different communities, goals and LICENSES.
For a gaming platform you might want to check out http://www.pubnub.com/. I met their CTO at a developer conference and for your stated purpose, you might just win big with not having to manage the infrastructure on your own. Check out their http://www.pubnub.com/customers/showcase for details on who is using their infrastructure and for what purpose.
For me, the main point is Kaazing has a proprietary license and it's payed. jWebSocket is LGPL and free. If you are developing an application with an ROI that allows you to pay for a service like Kazzing, I think it is a good option (like pubnub.com and pusher.com), but if you want to build a complete solution and host it or you want to contribute with OS community to create a new websocket alternative, jWebSocket is an excellent option.
There are two things I would add to Peter's comment, one is that Kaazing's emulation solution exposes identical APIs to the native WebSocket APIs, so you only have to learn WebSocket not some other proprietary API. You can check out the demos and the doc that Peter referred to for more information.
Secondly, Kaazing just announced the availability of Kaazing WebSocket Gateway AMIs on Amazon EC2 - http://kaazing.com/cloud
Best,
Jonas
I've been working with jWebSockets for the past 3 months or so, and this is the first I hear of Kaazing.
I will describe how I feel about jWebSocket so far to the best of my ability in the hope that it will help.
Setting up the developing environment and getting started wasn't easy but developing using it is rather comfortable. The entire system makes sense and it is quite easy to understand. You program with Java on the server side and js on the client using json based tokens, it makes it very easy to send and receive data.
It is however very lacking in support. There are a lot of missing documentation and the support forum is nearly dead. There is payed support from the developers but I've never tried it.
There are a lot of open source demos that you can use to understand and get started. Most of them were working smoothly. Something I cannot say about kaazing after a brief visit to their demo site.
In the few months I've been working with jWebSocket I've yet to encounter a single bug, The system works smoothly and my only disappointment is the lack of support and documentation.
If you are looking for a pure open source project, look at the Atmosphere Framework. License is Apache 2.
-- Jeanfrancois (creator of Atmosphere)
jWebSocket is a good framework and support almost all servers. It has support of jetty too. Only problem with jWebSocket is slow development and zero support. Websocket specification are changing very rapidly and jWebSocket releases are very slow. I would prefer to wait and watch jWebSocket framework for some time.
Related
Can we have an implementation of websockets in j2se?
I mean something similar to the old and not usable but lovely websocket4j?
I'm the author of an application server built in j2se. I don't care j2ee, I primarily use arrays, sockets, threads, db connectivity and filesystem access and it's all for my line. I just need to open to the websockets clientside world.
I don't need j2ee application servers. I don't want to use j2ee web containers. I need only to expand my application server build in plain java to be able to manage websocket sockets (http-handshaked sockets) as well as socket.
damn, somebody forgot the j2se implementation of the websockets?
I read it is not on plans (or only the clientside implementation), but I think what I'm asking should be already available; considered the coming importance of websockets. Isn't it? Why in J2EE only?
hope on some feedback.
thank you.
Your core question of "why" is probably a better fit for the OpenSource SE, but...
As an early adopter of Java, I'm sorry to say that there just isn't a whole lot of interest in J2SE anymore. Some of my favorite J2SE libraries have been coasting on "good enough" since the Java 1.4 days, and libraries for newer technologies are hard to find, as you've discovered.
The good news is that it might not be too hard to write one. There's a decent (can't say good because it's missing Javadoc) Socket.IO client library for Android that would probably be easy to port to J2SE. There are also a couple of server implementations floating around that I think have fallen behind in their support for current versions of Socket.IO. You could bring one of those up to date and port it. Maintain Android compatibility and it would probably attract a lot of support that would benefit both Android and J2SE.
Atmosphere
You might find the Atmosphere ( the Asynchronous WebSocket/Comet Framework) open-source project interesting. See also the Async-IO.org site.
I believe this runs on Java SE, as I use it in Vaadin web apps on Apache Tomcat on Java SE on Mac OS X.
Servlet Containers
Apache Tomcat, Eclipse Jetty, and other open-source Servlet containers run on Java SE with WebSocket code you can use.
Java EE is basically Java SE plus a bunch of jars. You can pick and choose various libraries to run on Java SE.
Wikipedia has a comparison of WebSocket implementations.
right answer came from #Paul:
Are you looking for something like this?
github.com/TooTallNate/Java-WebSocket
exactly.
I am new to mobile application development and wanted to know from experts here on how they approach the server-side design. I need to support cross platform clients (iOS, Android, Windows) and require a scalable backend architecture.
What are the widely deployed server-side strategies
Are there any Mobile specific open source server-side technologies available.
What factors people consider for mobile application back-end.
I agree with half the answer above. You should use REST architecture - it is the most straightforward way to go. I use Ruby on Rails for my mobile projects. It is quick to start building the server code and see it working in somewhere like heroku.com almost instantly.
So I'd pick the following:
ruby on rails - worth your time picking up
heroku.com for deploying / or EC2 if you pick the Rubber gem
Google App Engine is another great option if you know some python / java
REST architecture
store all your heavy images etc with Amazon S3. They have some great SDKs to work with.
get yourself some JSON libraries to communicate with your server
on iOS:
use MKNetwokKit (it will save you lots of trouble down the road. it helps you cache and its a nice architecture all around).
if the app is small, try a data model based on NSArchiver instead of CoreData (SLOWWW). Mogenerator is a good start (this isn't server related..)
If you hate writing server side, I'd advice you to checkout Parse.com. Completely mobile only development with all server code handled for you. For big projects, you really should write your own server stuff.
Some extra things I'd consider:
how would the security work? just a session token in the HTTP header?
tier your app -- networking / MVC
what happens when you're offline? - this is currently something we're dealing with after not having thought early - pain.
I've had good success with creating a server using REST web services and XML data, but would recommend JSON instead. You can create this using Java and host it using Tomcat. This is widely deployed and widely consumable by multiple mobile and even non-mobile technologies.
A couple of factors to consider:
* You'll probably want it in a DMZ and being Internet accessible so think about firewalls, reverse proxies, and encryption via SSL.
* Will you host the server or sell the server to customers? Hosting is easy. If selling, there are many more considerations.
I would like to implement a client-server architecture using JXTA. Also the configuration of the server part will be 3 - tier. Does anyone know a good place to get this project started?
Thanx in advance.
JXTA deals with p2p connectivity. This is the opposite of client-server approach.
From what I understand, you want to create a p2p network composed out of 2 nodes.
You can reach the site of JXSE (Java implementation of JXTA protocol) at http://jxse.kenai.com/Tutorials/Tutorials.html
Also, as far as I know, Oracle dropped its support for the JXTA project and the community intends to move it to Apache Software Foundation under the name Chaupal (there is a project on Google Code under this name: http://code.google.com/p/chaupal/).
I used JXTA for a personal project and it proved quite a beast (difficult to use and lots of bugs). I managed to do a simple p2p network. That was version 2.5.
Now it is 2.7 and I read it has improved. I couldn't find any tutorials for 2.7 though...
I could need your experience according server implementations for the currently evolving Websockets in HTML5. We want to use this technology for a project using common webbrowsers on the client site. What we now need is a webserver that feeds our requirements. These are:
written in Java or PHP since these are the languages which currently are used and mastered by all the programmers in the project. Since it seems that there are no promising PHP implementations yet, I tend to concentrate on the Java site.
as fast as possible. We don't expect too heavy usage in production but we need to be able to synch two browsers on independent host in nearly real-time.
easy expandable. We will need to implement our own protocol on top of the websockets so we would like the most possible flexibility.
easy to use, well documented and actively developed. Since we have to come to a first running implementation rather quickly and since I expect some changes in the developing people during the time, it would be great if it's not to hard to get into the server programming.
I already had a look on some servers/frameworks which look promising, e.g. Jetty, Netty and jWebSocket. I also found some older discussions of this topic. However, I would be glad about some current experiences or recommendations of those of you who already have used Java (or PHP) to work with Websockets. Is there some implementation which is especially well-fitting or one that we absolutely shouldn't use?
Edit:
For clarity: When I speak of implementing our own protocol on top of Websockets I mean having some kind of plugin mechanism so that we can use a Websocket to send XML-messages to the server and then use a plugin to interpret them into some server actions as we like. I guess every server implementation also supports this but it would be good if it was not too difficult to write such plugins.
I don't have any experience with PHP so I'll give you my opinion for the Java (and python side).
For Java:
You have your very common and safe choice of Tomcat. It's one of the most actively developed servers, its open source, lots of support/help from its very large community, from what I've read (but not tested) it can be fairly scalable and it also has a very mature console to monitor different metrics for your website.
You also have other choices such as Caucho's Resin, who have a very small yet smart team who actively develop their webserver. Their new heartbeat service allows a good degree of scalability (again from what I've read).
And then you also have Google's appengine which is all about scalability. Their API (for both, the server and client side) has started to focus on realtime web applications so it's a bit easier to for creating high performance web applications without having to worry about the server related optimization that you often have to make with other servers. They have APIs for creating "channels" between the server and client side for very realtime applications. The AppEngine team also has a new MapReduce API for analyzing data quickly/efficiently. For these reasons and the personal opinion that they are pioneering new web technologies/standards, I'm personally been leaning towards AppEngine. It's free if you're keeping cpu/data usuage low but if you need full scale deployment it does start to get pricey so do research. If your project is more for fun/school, its free quotas are enough and all its development tools/APIs are free so it's perfect.
For Python:
I'm more Java than Python, but Python is definitely a great language and very very very easy to learn. And the reason I'm recommending Python for consideration here is because AppEngine also allows developers the choice of Python. The author/creater of the Python language is now on the AppEngine team so, even though the Python and Java APIs are pretty much exactly the same, they sometimes have new/better APIs for Python. For example, I think the datastore API offered with Python is a bit easier and optimized for the Google datastore. Also, since you'd be using python, you can use Django with AppEngine.
The second choice that I've recently become aware of is the tornado web server which was developed by FriendFeed and then bought and used by Facebook. It's also actively developed. But the reason I bring this up is that Tornado's focus, much like AppEngine's, is high web application performance and scalability. I have no experience with it but I've become interested in its technology simply because no one can contest that Facebook requires a very high performance/scalable web server.
Some last thoughts:
In general you'll find that it isn't very difficult to build your own protocol on top of the APIs provided from most web servers (even Asp.NET MVC). But from what I've been able to test around with AppEngine, it really focuses on being flexible on what kind of protocol is build on top of it. To me, its pretty much just feels like a RPC server which which works on top of HTTP. And that becomes even more apparent if you use Python just because of some of the language constructs.
I will make a video chat website, but coming from PHP and Python for the web i have no experience with video steaming.
What do you recommend? Java or Flash? What's more flexible ?
I am thinking of even making a C++ server application for stream controlling with a PHP fronted. Since is going to be a high traffic website and performance is a must.
Can you point to some direction?
Any documentation? Framework?
I'm going to warn you: this is no small project. There's a reason why most prepackaged video chat websites and services cost hundreds of dollars a month.
First off, you need to pick your client side runtime. This is a major decision, since it will impact your available client base, and the cost of entry for your site. Flash is hands down the most pervasive, but Java is fairly prevalent in the techie culture. Silverlight less so, but you should check the latest statistics. Note that you should pick a particular version you're going to develop for, since the APIs may change, and market penetration is different.
Once you've developed the client-side code, you'll need to pick the server environment. If you use Silverlight, obviously you need to use C#.NET to develop the server side code (for the video streaming). Both Java and Flash as clients use Java as the server-end.
If you choose to go with Flash, be aware that you can either go with the official Flash Media Server, or you can go with the open-source Red5 server.
As noted by SEK, you should proceed with caution since providing a reliable streaming service might not be as easy as it sounds.
I would recommend reading about streaming (what it is/means, technologies, etc) and then moving on with the implementation.
Serving streams to clients
Solutions like the Flash Media Server, might give you less headaches. Red5, as previously mentioned is a 'nice' open source solution, although i am not sure about the capacity and stability.
You might want to check:
http://www.wowzamedia.com/ (Flash Media Server) - interesting
NOTE: Wowza Media Server 2 for Amazon EC2 is also available
http://mammothserver.org/ (Another Open source Flash Media Server)
http://fmsguru.com/ (Flash Media related tutorials)
Google is always your friend on this big topic..good luck.