Hello #all on StackOverflow,
i am currently developing a Server Client application which communicates over HTTPS and does some Task which have to run in a seperate thread on the Server aswell as on the Client.
I am not really concert about thread efficiency on the Client side.
The normal Server Task Looks like this:
HTTPS Server recieves Login equest.
Opens up one longpolling thread for communication.
Server recieves instructions to open
Server opens a Client socket and a thread to read from it.
Server recieves message to Close socket.
Clientsocket thread should wait now.
-Besides: The longpolling thread should wait() as long as it has not recieved any data from the socketthread.
So in most cases one user can ahve multiple sockets on the serverside so one session consists of:
LongpollingThread<1---1>USER<1---0..5>Socket
My question now is what is the best practise to get some decend scalability?
Is it better to write permanent Thread which has a while loop inside.
Or is it better to write Tasks which run on a Threadpool and die after one I/O cycle.
Can´t find a good answer online.
Maybe it is to specific..
Thanks in advance
Bladerox
I think you should use some kind of servlet engine or application server. Lots of your problems will be solved in there. Eg using async servlet processing will help you in your server component.
At client site: did you have a look at the multicast things in java.nio?
Related
I have to write a program in which clients send the server some number and wait to its response, other random number. It works Infinitely-send number and wait for response and so on...
I would like to write a server which gets a lot of connections ( and creates sockets) how can I do that in effeicient way (without creating thread to every socket created)?
Is it better to open and close sockets for every request and response?
Is there a way to send answer over a socket when I don't know which one is the right socket, but I know that all the sockets starts from the same client computer and I know the port source of the client
(I thought about making sockets array)
how can I do that in effeicient way (without creating thread to every socket created)?
You are assuming without proof that a new thread per socket is inefficient. It isn't.
Is it better to open and close sockets for every request and response?
No. Take a look at the history of HTTP. The major change between 1.0 and 1.1 was the introduction of persistent connections, which was done regardless of server-side architectures.
Is there a way to send answer over a socket when I don't know which one is the right socket
I don't understand how that situation could possibly arise. The answer only makes sense in the context of a specific session, which is associated with a specific socket. If you aren't retaining that information you should be. It's just a data structure problem.
but I know that all the sockets starts from the same client computer and I know the port source of the client (I thought about making sockets array)
If you can remember the source port you can remember the socket itself. Again, this is just a data structure problem. And there is no need for the assumption/constraint that all connections are from the same client. And unless that client is multi-threaded there is no need for multiple connections from it at all.
I started working on Java Socket programming. I had already made following apps:
1. client send message to server and server responds on recieving
2. client and server are chatting like Point to point chat
Now i want to develop an application in which, whenever a request arrives at server, it'll generate a thread for it. But now the problem is, i am unable to recognize the threads. If one thread is sending message then how server can identify that a message came from this client and i have to forward this to that client. how two clients (actually their threads) can communicate?
I searched on it, i found synchronized keyword and i know its use, i know about wait(), notify() and notifyAll() but still i am unable to provide a communication between them.
Please give me knowledge regarding this if i am doing something wrong or i need to know about some concepts before jumping into this one.
TIA
You cannot pass data to threads, you can only pass data to a data structure they are reading.
I suggest you use this simple pattern using two threads per connection and an output queue. These threads are created when the connection is accepted and run until the connection is closed. You can use a thread pool if you have short lived connections.
Each connection has a reader thread which reads from the socket until the connection is closed using blocking IO. THis reading thread also processes the work on the clients behave.
Another thread for each connection reads from a BlockingQueue for a message which it writes to the socket.
When a user connects they pass a unique token to say who they are and this is stored in a ConcurrentMap<String, BlockingQueue> where the BlockingQueue is the output queue for that connection.
This way whenever a connection sends a message to go to a particular users, you add it to the queue associated with that user.
You can reduce this model to use less threads e.g. with Selectors you only need one thread, but this is much more complex.
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 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 use an external mail server to send SMTP mails, this server is effectively beyond my control.
A couple of times recently this mail server has had issues and it's caused my Java (Struts/Spring) app to completely hang when waiting for a reply from the mail server.
I'm using the Spring org.springframework.mail.javamail.JavaMailSender to send mails.
When the external mail server is having issues it's the following line that freezes mailEngine.send(mailMessage);
I don't mind that sometimes emails don't get sent but how can I stop this from freezing my application while it waits for a reply from the SMTP server?
Are there any good email queuing solutions for Java?
You can send the emails in a background thread.
Thread your calls to the SMTP server. You can make use of the ExecutorService (various implementations exist) and drop in Runnables to be executed at a later stage (out of band). The advantage of this approach is that you don't have to explicitly code your threading model.
If you collect the Future object from the Executor upon submission, you can call get() with a suitable timeout and cancel (and perhaps re-submit/retry) upon timeout.