I am new to WebSockets with jetty, before I have used node.js together with socket.io to create a WebSocket Server. But due to different requirements I will have to use a java WebSocketServlet/WebSocket and was doing well so far using maven, jetty and the jetty-websocket plugin. My problem is, that I don´t found anything what was comparable to socket.io's socket.on(event, fn) implementation for the java solution. I would like to have the same possibility to react on different events fired from the client like "new", "addthis", "jointhat", ... send with some data as json or as POST param in the body. Is there any possibility or WebSocket Implementation which could do the same as socket.io?
Doing this "channel" stuff where I can implement the eventhandling on server side?
There is no custom event in WebSocket spec, and socket.io just follows their own protocol supporting custom event - https://github.com/LearnBoost/socket.io-spec
As far as I know, there is no Java implementation supporting custom event listening.
However, with Atmosphere, you can use socket.io client with Java web server, but I have not tested. https://github.com/Atmosphere/atmosphere/wiki/Getting-Started-with-Socket.IO
You might want to use other library in the client side like the jQuery Socket, if you want to control Jetty's WebSocketServlet directly. - https://github.com/flowersinthesand/jquery-socket/tree/master/samples/jetty-ws
Jetty's websocket implementation is only concerned with handling the basics of websocket.
Binary Messages (with fragmenting)
Text Messages (with fragmenting)
Ping / Pong
Close
There's been some brief discussion on supporting various new websocket subprotocols (odd name), such as WAMP (websocket application messaging protocol). But those would just be built on top of the basic websocket layer.
Another choice is to use something with a full channel api like CometD and just configure it to use websocket and not fallback into older communication formats.
Related
My application uses a custom binary protocol which is implemented with Netty. Recently I changed it to use Netty's websocket implementation. It works quite well.
My application also has a Jetty web server included and it offers websockets, too. Now I want to reduce the opened ports my server needs and handle all http traffic with one port.
I see three options:
Use either Netty or Jetty to proxy the traffic which belongs to the other implementation.
Reimplement the custom protocol on Jetty without the use of Netty's channels and piplines.
Create a custom implementation of Netty's channels that sends and receives it's data not over a socket but the methods Jetty's WebSocketListener offers.
Since Netty provides such a good api for writing binary protocols and a proxy sounds like extra problems to me I tend using the third approach. It shouldn't be too difficult to implement even though I don't know how to do it, yet.
Any thoughts what would be the best option and how I should implement it?
I want to develop a Java server that is able to send messages asynchronously to a client in form of a website with JavaScript. I know that one possibility is using WebSockets, but these are not supported in IE 9.
For transmitting messages from client to server I can use AJAX calls with maybe a RESTful Interface on the server side.
Does anyone have a solution for this?
This is not how webservers work, most of the time. HTTP Webservers are inherently a request-response architecture:
HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client.
That said, there are technologies that you can use to do this. Read here about Comet and Reverse AJAX:
Is there some way to PUSH data from web server to browser?
You better implement your Java server to act as a Websocket server when it's supported by the end user. For the users who does not support Websocket it should fall back to long-polling.
This behaviour will avoid unnecessary overheads due to long-polling communications whenever possible.
The good thing is you don't have to implement all these behavious from the scratch. You can readily embed and use a reliable implementation available open source.
One such implementation is CometD project. The CometD project was available for more than a decade and it has evolved to solve most of the issues.
If you are looking for commercial products, there are many available. One such would be lightstreamer (http://www.lightstreamer.com).
You need to use a design pattern like long polling since WebSockets is not available. Rather than build it yourself you could use a library like SignalR. SignalR is an ASP.NET library but there is a client for Java (https://github.com/SignalR/java-client)
For anyone who comes across this question more recently, the modern answer (as of early 2021) supported across all browsers (except IE, which even Microsoft has given up on in favour of Chromium-powered Edge) are server-sent events. A most elegant and standardised solution to providing a pub/sub model to web clients.
Hi I am working with java and thrift. I see that there are 2 parts to the thrift Async system one is the Service.AsyncIface and another is Service.AsyncClient. From the thrift implementations for AsyncClient, I see that the non blocking interface is wired up and ready to go on the library side. I just made a simple client using TNonBlockingSocket and it works
1) Do we care if the existing thrift server for the Service is blocking or non blocking? Why?
2) If we want to wrap a nonblocking client framework in things like retry logic, host discovery, policy management etc what would be the ideal framework?
From client's point of view there's no difference in communication with sync or async server given that protocols and transports are compatible. That's because the client should receive the same serialized response from both sync/async servers. For example, if you do JSON over HTTP request, you don't really care if the server is sync or async.
Finagle is a good choice if you're interested only in JVM languages (and it's the only framework I'm aware of that has required feature set).
I need to push events to web clients in a cross-browser manner (iPhone, iPad, Android, IE/FF/Chrome/etc.) from a Spring based Java server. I am using backbone.js on the client side.
To my best knowledge, I can either go with a Web socket only approach, or I can use something like socket.io.
What is the best practice for this issue, and which platform/frameworks should I use?
Thanks
Looks like you're interested in an AJAX Push engine. ICEPush (same group that makes ICEFaces) provides these capabilities, and works with a variety of server- and client-side frameworks. There is also APE.
You can have a look at Lightstreamer.
My company is currently using it to push real time financial data from a web server.
I suppose Grizzly or Netty may fit your needs. Don't have a real experience in that scope, unfortunately.
I'd recommend socket.io as you mentioned in your question, if you're doing browser based eventing from a remote host. Socket.io handles all the connection keep-alives and reconnections directly from javascript and has facilities for channeling messages to specific sessions (users). The real advantage comes from the two-way communication of WebSockets without all the boilerplate code of maintaining the connection.
You will need to do some digging for a java implementation thoughConsider running the server directly from V8.
I am trying to learn about the Jini API in java, but can't get my head around how the server and client interact, and am constantly seeing things being referred to as "smart proxies". What are smart proxies? And how does the client and server interact ?
Thanks.
Jini is based on Java RMI, so clients and servers communicate with each other just as they do in RMI: request/response using RMI protocol on the wire.
As for the "smart proxies", the Jini compiler uses a proxy factory to generate implementation code for your interface that includes an API for sending and receiving meta data about services. This is the magic that makes it possible for a client to send out a request for a certain kind of service on the network (e.g. "I'd like a color laser plotter") and select from the responses to find the best match possible.