I have to design a client/server system emulated on a website running Ruby on Rails that should work like this:
a page is requested by a web browser and once it's opened the server can push messages to it
I know this is not possible "naturally" but I was thinking of a sort of "java applet" that is running on that page, listening on a port for messages to be sent by the hosting server. This should be done opening a sort of a socket that listens on some port where the server can connect to send its messages.
Can this be done? Do I have to develop a java server thread or can I simply address the client applet via it's ip address and port and use any web service connection from the server?
thanks,
Luca
Comet is definately what you want. Depending on your needs, you can host your own comet server, or use a SaaS solution, such as WebSync On-Demand (disclaimer: I work there). Using the SaaS stuff, you get server-push capabilities without having to actually run your own comet server.
The easiest way to do that is to use Javascript to emulate the push mechanism. Polling in regular intervals using AJAX is sufficient in most cases. Have also a look at Comet.
An alternative to using a java applet may be to use a combination of javascript and an approach known as Comet. In a nutshell, Comet is a way to enable server push over HTTP. I'm not really a ruby on rails guy, but a quick google search for ruby on rails and comet nets a fair amount of useful information.
have you looked at juggernaut
If you want go the applet route, you need to make the connection from applet to the same server where the web page is served. The applet can't listen. Once the TCP connection is established, it's a 2-way channel, you can pull or push as long as your protocol allows it. This is how it's done with most Applet-based chat clients.
More and more people are simply using long polling in Javascript. It's pretty involved to get a reliable long polling system running, I would suggest you to use a framework. For example,
http://cometdproject.dojotoolkit.org/
Related
What are the possible ways in which Java Swing Application which is running on client side can communicate with server?
I've read that JSP can be used in web pages to communicate between server and client.But, is it possible to use JSP with Swing application? if so, how? It would be helpful, if it is demonstrated with simple login form. Thanks.
Any client-side application, whether it be a java swing app or otherwise, can certainly communicate with any server (assuming no network limiting architecture -- firewalls and whatnot). Your options are numerous
Raw sockets
Any one of the myriad of network protocols.
HTTP/HTTPS
FTP
SCP
et. al.
It depends on what protocol, services and applications are available on the server to connect with.
HTTP/HTTPS is very common. You'll need to manually create HTTP requests and send them to the server (assuming the server is a web server).
I am planing to develop JavaScript client application that will connect to Java server using websocket. Server should handle many connected clients.
After some reading I found out websocket single thread. This is not good if I want to run databases query that can block everything for a while.
What I am thinking about is to opening separated websocket for each JavaScript client. One socket is listening for new connection and when connection is established creates some unique id. After that opens new websocket and send id to client using listener socket. When client received id close first socket and connect to new one.
What do you think, is it good solution? Maybe I am missing something?
Spring 4 gives you the chance to use a thread pool. The documentation is here:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html
You could use Akka to manage all the concurrency and thread management for you. Or you could use the Play Framework that already builds on Akka and that supports WebSocket quite nicely. With Play you can choose between Java and Scala on the server side.
You should use NodeJS on the server to handle the socket i/o. You can connect to it via your javascript client apps, and then make calls to your Java based API. NodeJS is non blocking (async) and you should be able to leverage your existing Javascripting skills to quickly build a Node app. You could even use a full MEAN stack to build the client/server app. http://meanjs.org/ or http://mean.io/#!/ are two popular places to start.
I would like to have the clients query each other through the server without delay ( = no polling interval ).
Example: Server S, clients A and B
Client A wants to request Client B.
Client A will make a request to the server S, no problem there.
Then Server S needs to be able to request Client B but how to do that without polling?
All the node.js/APE (for PHP) technos are designed for the web, however I don't use a web server for that. Does Java has something close to a push technology/framework that is not web?
I would really prefer a solution that doesn't require each client to use their own reserved port (I don't want to end up with 1 WebService per client for example)
Note: all the clients are on the same machine.
A couple of options...
Plain socket communication. java.net.Socket, java.net.ServerSocket. Maximum flexibility but requires knowledge of low level TCP/IP API/concepts.
The good old RMI. Java based RPC layer on top of TCP/IP. Works good when client and server are both in Java and generally in same subnet. May give problems when client and/or server are natted.
Spring Remoting, it's actually pretty decent.
Bi-Directional Web Services. i.e. clients host their own WSes which the Server calls when it needs to do a callback.
JMS as someone already mentioned.
Distributed Data Structures, Check out http://www.hazelcast.com/
Lots of options to chose from, no need for webserver.
If you really don't want to use a web server then I would check out JMS. That being said, all the cool kids are using web servers these days since the protocols are so ubiquitous.
Your use case requires a messaging protocol. We don't really know the scope of your problem but you already said you want a server to exchange requests between clients, so I would go with an existing solution rather than a roll your own approach.
JMS has been mentioned and is certainly a viable Java based solution, another would be XMPP which is a real time communication protocol commonly used for instant messaging.
It is an open standard that has both server and client support in every major language and platform. This would allow you to have standalone apps, web based ones and apps for mobile devices all being able to communicate with each other. The only potential gotcha for your use case is that it is text based. Since you haven't said what requests you want to pass back and forth, I don't know if this will fit your bill or not.
You can use Smack for client side development in Java and any OS server you want.
which is the best method to send a numerical value data from a javscript webpage to a web server port.. i have a server socket program running on the server and listening to port 5000.
i need to send data from a webpage to the port? which is the best method?
the scene is this.
i have a C socket program running at a web server hosted in my laptop using XAMPP.
it is listeing to a port 5000 and also i have my ip address. in the web page,
i am running a javascript and when the user presses any of the arrow keys i need a value to be sent to this port.. like up -1 , down -2 etc ...
There isn't currently any way to do this in a portable fashion. Some browsers support the WebSocket standard, which gives you some limited access to sockets, but this isn't currently available in any common browsers other than Chrome and Safari. The Flash player supports a separate XMLSocket protocol, which you can also use if the Flash plugin is available. However, neither of these protocols supports raw access to sockets -- both require some initial negotiation and packet framing.
Because your web server is running on a different port than your socket program, the Javascript in the browser is restricted from making requests directly to the socket program because of the Same Origin Policy. However, there are various ways to get around this restriction. Alex Sexton has a lengthy overview of all the different ways of doing this. However, all of those ways require that your socket program be running the http protocol also.
Socket.IO seems like a perfect fit for what you are trying to do, but you'll probably need to ditch your C program.
The only way to open a network socket connection from a web page is to use a Java or Flash app to make the binary socket connection. You could then use java script to pass the data to the app which would connect and forward it to the server.
Alternatively you could use some server side code and AJAX to proxy the connection and forward the data.
The second option doesn’t rely on any browser plug-in being installed and I think would be easier to implement. It would also be able to forward to a port that is not on the web server itself as it wouldn’t be subject to browser security restrictions.
I guess making one ajax request to required port on a server... can solve the request.
I'm writing a backend for a mobile web-app based in Java and I was wondering as far as scalability and ease of use go what are the pros and cons associated with using WebSockets versus Long-Polling solutions like comet. Another option would also be implementing my own solution using TCP. From what I've read it seems that you need to run Long-polling solutions on dedicated servers as they don't run well in Tomcat/Jetty when you start dealing with large numbers of users. WebSockets sounds like it scales better. Are there any disadvantages to going with Websockets over Comet or should I just resort to my own solution using TCP connections? I'm looking for the option that uses the least traffic.
I guess it depends on your usecase and tolerance for learning new things but, for sure, going down the path of using WebSocket APIs for communication, or even SSE, would better than a traditional long-polling/Comet solution for many reason - one that you mentioned - scalability, but also for bandwidth utilization and latency. It is important to also understand that WebSocket is to the Web what TCP is to the desktop e.g. a socket. In a desktop solution you don't necessarily code against TCP, you use a client library supporting a transport protocol like STOMP or XMPP over TCP. You do the same when using WebSocket, pick a server to communicate with e.g. XMPP server, and a XMPP client library to communicate with the server over WebSockets.
You can see our example of it here and we have docs you can read here.
The thing to watch out for is browser adoption of HTML5 WebSocket - currently in Chrome and Safari, and coming soon in FF and Opera. We have addressed this, but in case you plan to build your own server you will have to create a fall back solution for older browsers.