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.
Related
I'm developing an Android app using a server side for computations and message handling. I need to work with push notifications, so I decided to go with Socket and ServerSocket.
For now, my server side is just a pure JAVA code that receive requests and open sockets accordingly. Is there any framework for my purpose? And how should I run my server side app on a remote server, should I create a runnable jar or is there any other way?
You can use Apache MINA, which is a socket framework with useful features like NIO, session management, SSL and other filter support.
Using a reliable framework means you spend less time writing boilerplate code.
Yes, you can create a runnable jar and create a bat/sh script to run on your server. Read this article for more information on packaging applications.
I'm going to create an authentication server which itself interacts with
a set of different Oauth2.0 servers.
Netty seems to be a good candidate to implement network part here.
But before start I need to clear some details about netty as I'm new to it.
The routine will be as follows:
The server accepts an HTTPS connection from a client.
Then, not closing this first connection, it makes another connection
via HTTPS to a remote Oauth2.0 server and gets data
After all, the server sends the result back to the client which is supposed to keep the connection alive.
How to implement this scenario with Netty?
Do I have to create a new netty client and/or reconnect it each time I need to connect to a remote Oauth2.0 server?
If so, I'll have to create a separate thread for every
outgoing connection which will drastically reduce performance.
Another scenario is to create a sufficient number of Netty clients
within a server at the beginning (when server starts)
and keep them constantly connected to the Oauth2.0 servers via HTTPS.
That's easily done with Netty. First you set up your Netty server using the ServerBootstrap and then in a ChannelHandler that handles your connection from the client you can use e.g. the client Bootstrap to connect to the OAuth server and fetch the data. You don't need to worry about creating threads or similar. You can do it all in a non-blocking fashion. Take a look at and try to understand how this example works:
https://github.com/netty/netty/blob/master/example/src/main/java/io/netty/example/proxy/HexDumpProxyFrontendHandler.java#L44.
My service already uses Websockets to communicate with an HTML5 in-browser client. The client is served by the same server from a normal http request.
Now I would like to offer the same service/app but out of the browser, and I would like to offer it over TCP sockets.
The RPCs/action object I am using are going to be the same, the serialization is going to be the same, the logic is the same. I just want to use TCP socket instead of WebSocket.
I would like to keep the code together under the same "project folder", starting all at once when I deploy the playframework server (basically on start I want to start listening to WebSockets, TCP sockets and http requests), and have everything in the same package on deploy.
I know that:
It is not necessary, since WebSocket can be used in not-in-browser apps, but consider this an exercise or a curiosity question.
playframework is built on top of netty, and I used netty before to do some TCP services (nothing big and nothing prod ready though ... so not an expert). So they should work together right?
What I was thinking to do:
Have an akka actor listen for new socket connections.
Wrap the connections (WS or TCP sockets) into a ClientConnectionManager instance
Pass it to the actors that takes care of the connections/rpc logic.
Other leads I considered: Reimplementing the playframework Controller class.
Or is there an already implemented solution for this?
I am looking to build an instant messenger in Java.
Clients will connect to the server to log in.
They will start a conversation with one or more other clients.
They will then post messages to the server that will relay the messages to all the clients.
The client needs to be continually updated when users post messages or log in.
so the way I see it, the client needs to run a server itself in a separate thread so that the main server can send stuff to it. Otherwise the client will have to the poll the main server every xyz seconds to get the latest updates. And that would need a separate thread anayway, as that would be purely for getting updates whereas the 'main' thread would be used for when the client initiates actions such as posting messages/inviting others to conversations etc...
So anyone recommendations on how to write this instant messenger? Does it sound like a good idea to make the connection a 'two-way' connection where both the client and server act as servers? Or is polling a better option? Anyone know how the IRC protocol does this?
There's no real advantage of having 2 connections unless they can be handled independently (for example receiving / sending a file usually done in a separate connection). A connection itself is already a two-way communication channel so it can be used to both send and receive messages, events etc. You don't need to poll server since client is able to maintain persistent connection and just wait for data to appear (optionally sending periodic PING-like message to ensure connection is alive).
IRC uses a single connection to server to exchange text commands. For example one of the main commands:
PRIVMSG <msgtarget> <message>
This command can be originated either by client or by server. Client sends PRIVMSG to notify that it wants to deliver message to one or more destination (in IRC this either user(s) or channel(s)). Server's task here is to properly broadcast this message to appropriate clients.
If you're using raw InputOutput streams then yes this is a good way of doing it. You create one thread on the clientside that acts in a similar fashion as the server thread - waits for any incoming updates and when it does it updates the client. I wouldn't call it a server though. So you'd ideally have 2 TCP/UDP connections one for requests made by the client and one to notify the client of server changes.
This solution in an enterprise environment would probably be done through some kind of messaging framework such as Spring Integration but dig deep enough and it will essentially be a similar way to how you mentioned.
Do you need a fully custom protocol or would it be sufficient to use the XMPP? There are several open source libraries implementing XMPP.
http://xmpp.org/xmpp-software/libraries/
e.g. http://www.igniterealtime.org/projects/smack/
For me, to develop instant messaging service, I will use websocket protocol instead of normal java socket because the normal socket can not work well with HTTP protocol and moreover some network providers and firewalls banned custom ports. If you develop it in normal socket, your service could not be accessed by web clients.
Did you plan to develop the instant messaging service yourself? How about using other protocols such as Jabber?
I am brand new to the Java EE world. As an exercise to try and familiarize myself with Java EE, I'm trying to create a tiered web-app, but I'm getting a little stuck on what the best way is to spin up a service in the background that does work.
Parameters of the service:
It must open and hold a socket connection and receive information from the connected server.
There is a 1-to-1 correlation between a user and a new socket connection.
So the idea is the user presses a button on the web-page, and somewhere on the server a socket connection is opened. For the remainder of the users session (or until the user presses some sort of disconnect button) the socket remains open and pushes received information to some sort of centralized store that servlets can query and return to the user via AJAX.
Is there a Java EE type way to handle this situation? Naturally what I would think to do is to just write a Java application that listens on a port that the servlets can connect to and spawns new threads that open these sockets, but that seems very ad-hoc to me.
(PS: I am also new to Stack Overflow, so forgive me if it takes me some time to figure the site out!)
There are three main containers in the Java EE stack: the Web container, the EJB container, and the JCA container. JCA is meant to provide inbound and outbound connectivity with third-party systems, such as database, JMS broker, or others.
The "right" way to create an connection to a Telnet server from an EJB or web app would be to use a JCA connector for that.
[client] <-|-> [web] <--> [ejb] <--> [jca] <-|-> [telnet server]
The pipe | denotes remote boundaries. A assume EJB are locals, but they are optional anyway; you can use JCA connector from the web layer also.
I suggest you investigate if there are existing implementation. A quick google gave me this result: JCA connector for Telnet client.
Another approach (but not compliant with the spec), is to start the thread that listens to the socket from a ServletContextListener. The thread will run in the web layer and you can manage connectivity with the Telnet server as you wish.
I suggest you have also a look at this other SO question: Java EE application that listens to a socket.
In both cases, you will probably need to figure out how to temporary store the information received by the Telnet server (the centralized store that you mention) that will later be displayed in the web interface. This is again problematic with Java EE, because the spec forbid the usage of global state. For instance, you should not use static field in theory. But in practice that works if you have only one instance of your app running.
That's only a rough sketch, but I hope it helps.