I am writing a program to demonstrate the distance vector routing algorithm. This program creates multiple routers and their routing table. Each router is its own thread using a two-dimensional array. I need to have the threads send their tables to one another. I am not sure how to communicate between these threads. I looked into sockets but am not listening on any ports. I am not sure how to use pipes or if this is the best option or not. Any suggestions would be helpful.
If you run two different processes, you can use Sockets, JMS or files to share information.
If you run just two threads in one process, you should create some thread safe storage, say ConcurrentLinkedQueue for this. Here is more of them http://javarevisited.blogspot.com/2013/02/concurrent-collections-from-jdk-56-java-example-tutorial.html
Have each Runnable or Thread that implements your routing thread expose (say) a java.util.concurrent.TransferQueue<YourTableType> and deliver your tables to it. The routing thread can pull the tables from the transfer queue at it's leisure.
The java.util.concurrent package is extremely well documented, so it's worth having a good look around in it.
Why don't create a server/client and make the call from the client to the server and then the server send the answer to the other client ?
You'll need to create 2 files, server.java and client.java,
Make the connection client/server via TCP,
Messages from client to client via UDP;
If you need any help just ask, I've made a few projects like that in university.
Related
In Java is there a way to connect multiple clients to a server at once without creating multiple threads? I want to create a buzzer-beater for a trivia game I'm making for my friends and I. However, I don't want the server to only be listening to one thread (or contestant) at a time. I'd like the server to be constantly listening to all clients and track the order in which they each hit the button on the client GUI I made.
Not looking for specific code, just ideas. Is a multi-threaded server even the right approach for this sort of problem? Is there a better networking solution in Java?
Thanks!
I am using the RabbitMQ java client.
My app has multiple exchanges and queues. Adopting something similar to the Pub/Sub model.
What is the best practice regarding connections?
Shall I have one connection per app?
I understand the channel model, and the thread (un)safety model. Just not sure if I should have multiple connections or not.
One connection per app is correct.
Within that connection, you will have many channels - where the actual work is done.
You can have hundreds or thousands of message producers and consumers (each on their on channel) inside a single connection.
If you start to see slowdown in your RMQ setup because you're dong too much work, look at clustering RMQ and/or standing up multiple instances of your app.
But you would still maintain 1 connection per app instance.
It will depends on the volumetry of messages you will have. If it really is huge, maybe 2 or 3 connections could do it, but one per application seems to be the best choice
At the moment I have a project where we develop a Java Texas Holdem Application. Of course this Application is based on a client server socket system. I am saving all joined clients (I'm getting them with socketServer.accept() method) in an ArrayList. At the moment I make one thread for each joined client, which permanently checks if the client send any data to the server. My classmate told me it would be way better if I create one big Thread, that iterates through the whole Client ArrayList and checks every Client inputstreamreader. Should I trust him?
Creating a thread per Socket isn't a good idea if your application will have a lot of clients.
I'd recommend into looking into external libraries and how they handle their connonections. Example: http://netty.io/, https://mina.apache.org/
Both approaches are not feasible. Having a thread per connection will quickly exhaust resources in any loaded system. Having one thread pinging all connections in a loop will produce a terrible performance.
The proper way is to multiplex on the sockets - have a sane number of threads (16, why not), distribute all sockets between those 16 threads and multiplex on those sockets using select() variant - whatever is available in Java for this.
I'm creating a Networking Utilities package, to make it easier to create network applications, like chat applications, games etc. I wonder if it's possible to, in the server thread, look for packets all the time, without blocking the thread?
I want to do this, because, for example, when I'm going to create a multiplayer server, I don't want the whole server to be blocked and unplayable because the server is looking for packets that tells the server that someone is connecting.
What's the best way of solving this?
To put the joining detection in a separate thread?
Also; how many threads can you run in a single application? Should you try to hold the amount of threads down as much as possible? Is 4 threads too much?
Edit: I put the join detection in a separate thread and class. Then, while the join detector was active, it checked for packets and added them to a list of requests. Then, from the server class, every update, i checked if there was any gathered requests in the join detection class.
Sorry for the wrong answer before.
I am just trying to understand how to write a thread-per-request TCP server in Java.
I have already written a thread-per-connection server, that runs serverSocket.accept() and creates a new thread each time a new connection comes in.
How could this be modified into a thread-per-request server?
I suppose the incoming connections could be put into some sort of queue, but how would you know which one has issued a request & is ready for service?
I am suspecting that NIO is necessary here, but not sure.
Thanks.
[edit]
To be clear - The original "server" is just a loop that I have written that waits for a connection and then passes it to a new thread.
The lecturer has mentioned "thread-per-request" architecture, and I was wondering how it worked "under the hood".
My first idea about how it works, may be completely wrong.
You can use a Selector to achieve your goal. Here is a good example you can refer.
You can use plain IO, or blocking NIO, (OR non-blocking NIO, or async NIO2) You can have any multiple threads per connection (or a shared worker thread pool) but unless these are waiting for slow services like databases, this might be any faster (it can be much slower if you want low latency)