Spring integration has excellent example to TCP Server. But it seems to be using single thread for every socket connection.
Is there any example on how to create TCP Server which can process requests with multiple threads? Better yet, is there any example to use thread pooling in TCP Server.
I would appreciate if you can provide any links.
Thanks
Set using-nio="true" when processing a large number of sockets and a thread pool is shared across the connections.
For a small number of sockets it's generally faster to use a single thread per socket.
Related
I'm working on a BitTorrent Client and I need to setup a TCP connection for each peer. I read online that you can't set up a second active socket untill the first is closed, with a client socket.
Would setting up a multithreading server work just as well for managing each separate concretion?
I just need to read and write byte packets following the protocol to each IP/Port pair. Preferably in separate threads so multiple blocks can be downloaded across multiple torrents at the same time.
Whats the best way to approach this?
Writing any kind of web server in Java (be it a webserver, RESTful webapp or a microservice) you get to use Sockets for dual channel communication between client and server.
Using the common Socket and ServerSocket class is trivial, but since Sockets are blocking, you end up creating a thread for each request. Using this threaded system, your server will work perfectly but won't scale very well.
The alternative is using Streams by means of SocketChannel, ServerSocketChannel and Selector, and is clearly not as trivial as common Sockets.
My question is: which of these two systems are used in production ready code? I'm talking about medium to big projects like Tomcat, Jetty, Sparkjava and the like?
I suppose they all use the Stream approach, right?
To make a web server really scalable, you'll have to implement it with non-blocking I/O - which means that you should make it in such a way that threads will never get blocked waiting for I/O operations to complete.
Threads are relatively expensive objects. For example, for each thread memory needs to be allocated for its call stack. By default this is in the order of one or a few MB. Which means that if you create 1000 threads, just the call stacks for all those threads will already cost you ~ 1 GB memory.
In a naïve server application, you might create a thread for each accepted connection (each client). This won't scale very well if you have many concurrent users.
I don't know the implementation details of servers like Tomcat and Jetty, but they are most likely implemented using non-blocking I/O.
Some info about non-blocking I/O in Tomcat: Understanding the Tomcat NIO Connector
One of the most well-known non-blocking I/O libraries in Java is Netty.
I'm trying to build a multithreaded server with TCP connections, that can talk to multiple clients and concurrently stream some data. I am using Java, Java IO and Java Thread libraries. I believe my implementation should be built as a 'thread per request' model. Any idea where I can kickstart or a tutorial you can point me into?
A thread per request model is quite simple to write, as multithreaded code goes. Basically what you need is:
A thread pool
A server socket
A main thread that dispatches worker threads
Set up the server socket to listen for requests. Have the main thread run a loop. The loop waits for a request to come in, then takes a thread from the thread pool to service the request.
If you want to write a efficient Server. Use NIO. One thread per client is old way. It's memory/cpu intensive.
See this one. This is a good place to start.
http://rox-xmlrpc.sourceforge.net/niotut/
Once you understand NIO and implement your server that way you will be glad you implemented it. In past I converted a One thread per client model to NIO and performance gains were tremendous.
How do you implement a Thread that handles client requests on the server using UDP. I have read somewhere you can use ThreadPoolExecutor, is using this method ok. Becuase there isnt much articles on the web that give you any examples of using Multithreaded UDP applications.
So my question is should i use ThreadPoolExecutor?
Does someone have an example of how to implement A Multithreaded UDP Server/ Client application?
This is simple to do using TCP so i have used TCP Multithreading, just wanted to grasp how UDP works this way.
The thing is Executors is not at all an issue here. It doesnot matter if you use a ThreadPoolExecutor or use manual threads to do it. ThreadPoolExecutor or any other ExecutorService for that matter is just a service to manage threads and work accordingly. It has got nothing do with what your RUnnable's or Callable's are.
In your program you will only be giving Runnables or Callables to a executor. ExecutorService doesn't care of what is inside the runnable because its his job to execute them. So the way of using ExecutorService for TCP server or UDP server doesn't change as far as dealing with ThreadPoolExecutor. Just modify the RUnnable to be sent and all done :)
The main trick with UDP is that it is unreliable. You have to implement your own detection/handling of lost packets.
Once you have requests, you can use an Executors.newXxxxxx() just the same as TCP.
In our new project we need to implement a server application. This server gets connection requests of 50,000(+) clients. Problem is these connections have to remain open and have to be managed somewhere. The application should work like a telephone exchange. So it can get requests of connected clients and connect them to other (maybe several) clients only if they are also connected. A proprietary protocol is used. My questions are:
How (and where) to manage the open sockets? Should I put them in a HashMap or something? This sounds curious to me. But I don't have experiences with so many open connections.
Are there any frameworks available which support this connection requirements?
Thank you for your help!
How (and where) to manage the open sockets? Should I put them in a HashMap or something?
Typically each socket will be managed by a thread that will be responsible for reading and writing to the socket. You would also have a master thread that is responsible for receiving all connection requests at a predefined network interface & port (using the ServerSocket API class), which may then hand off the actual processing work to the worker/slave threads. In this case, you ought to be looking at a thread pool for the worker threads, because creating 50k threads will most likely overwhelm your OS and the hardware.
Also, if you are indeed managing 50k concurrent sockets, using NIO API (java.nio.*) over the plain IO API of Java is highly recommended, although I haven't seen too many projects requiring more than 2-5k concurrent connections. There are atleast two known NIO based frameworks in the Java world - Apache MINA and JBoss Netty. I would however recommend reading the well written NIO tutorial, before heading onto use the NIO API or the NIO frameworks.