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.
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!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Currently I am going about making a chatting program (in java for those who are wondering) and I am at the point where I need to come up with a good architecture for the whole thing. This is my current outline, but feel free to provide any feedback (I have no professional training, just some reading).
Client Side:
The lifecycle will be as follows:
Connect with the server- First I plan to have the client establish a connection with the server, prompt the user to login or create a new account, and send these credentials to the server, which will then send back information like the users list of friends and any other relevant data I can think of.
Waiting for the user to connect with someone- There will be a list of friends who are currently online and that the user can connect with and a button to find and request other users to be friends with them.
Chatting- I'll go into more detail on the server section, but the user will send text and images to the server which will proceed to rout it to the other user.
Rinse and Repeat- After the user is done chatting, it will go back to step 2 until they exit out of the program, at which point it will close all connections with the server.
It seems that the client side only needs to be single threaded. Also, if you think of any useful (major) features that many IM type programs have, please share them. I'd be happy to hear (if you want to make me very happy then you could include a general outline for the implementation also :).
Server Side
Now this is where it gets rather messy. I think that I am creating way to many threads than I need to. Let me explain.
The server stores information on each client using a JSON representation of each user. As well, a list of users currently online is maintained.
Current idea for what chatting looks like server-side:
Connection established with one client- The server and client communicate and get the client logged in (or registered), the server tells the client who its friends are, and the client is added to the list of users currently online. As well, at this point I am starting a new thread to listen for input from this client
A client chooses to start a conversation with someone- At this point I think I need to create a new thread for this conversation, as many of these need to be going on at the same time. As of now my idea is that I start a new thread on the server side which handles all of the routing and comunicated with just those two clients in the conversation.
Wait for more users to connect- Although I don't ever anticipate more than two people to connect to my server, I would like to make it so that in theory the server can handle multiple conversations. This I believe would be my main thread, waiting for someone to connect then creating a listener thread for them. Once a conversation is set up, this thread would give that conversation its own thread and then go back to what it is doing. This should be able to be done in just one thread (at least according to my logic).
And that's it. Now, of course there are things like graphics and whatnot that I didn't include. Also, with what I have so for in Java I should be able to make conversations between more than two people. Nonetheless, this seems like I am using an excessive amount of threads. There is the main thread, one thread per user, and a thread per conversation. This means that with 1000 users chatting I've started 1501 new threads. Is this excessive? Could I use some type of thread pool? What other suggestions do you have? If I missed anything, just ask (if its something that I haven't thought of then I'll say that too). Finally, if you have any ideas for the actual features of the program, I'd be glad to hear.
Neither one thread per conversation or one thread for all conversations is going to scale. You need something in-between.
Using a thread pool that has some maximum number of allowed threads, for each message received for the conversation, queue up the processing of the message to the thread pool.
As long as there are threads available (i.e., you don't have too many messages to process at once), the message should be processed immediately.
If there are more messages to process than threads in the pool, there will be a delay in processing some messages. Though this isn't ideal, like the comment said a chat program requires fairly low processing/bandwidth, but managing the maximum size of the thread pool means you're not going to thrash the processor or run out of memory. Ideal for a scaling solution.
As you increase the hardware size, the number of concurrent threads can increase, though that doesn't sound like it'll be a problem here.
I advise you to use www.netty.io.
there are some tutorials to develop chat client/server :
http://www.allreadable.com/6b8c8U4g
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 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.
I am building an android app that communicates with a server on a regular basis as long as the app is running.
I do this by initiating a connection to the server when the app starts, then I have a separate thread for receiving messages called ReceiverThread, this thread reads the message from the socket, analyzes it, and forwards it to the appropriate part of the application.
This thread runs in a loop, reading whatever it has to read and then blocks on the read() command until new data arrives, so it spends most of it's time blocked.
I handle sending messages through a different thread, called SenderThread. What I am wondering about is: should I structure the SenderThread in a similar fashion? Meaning should I maintain some form a queue for this thread, let it send all the messages in the queue and then block until new messages enter the queue, or should I just start a new instance of the thread every time a message needs to be sent, let it send the message and then "die"? I am leaning towards the first approach, but I do not know what is actually better both in term of performance (keeping a blocked thread in memory versus initializing new threads), and in terms of code correctness.
Also since all of my activities need to be able to send and receive messages I am holding a reference to both threads in my Application class, is that an acceptable approach or should I implement it differently?
One problem I have encountered with this is that sometimes if I close my application and run it again I actually have two instances of ReceiverThread, so I get some messages twice.
I am guessing that this is because my application did not actually close and the previous thread was still active (blocked on the read() operation), and when I opened the application again a new thread was initialized, but both were connected to the server so the server sent the message to both. Any tips on how to get around this problem, or on how to completely re-organize it so it will be correct?
I tried looking up these questions but found some conflicting examples for my first question, and nothing that is useful enough and applies to my second question...
1. Your approach is ok, if you really need to keep an open connection between the server and client at all time at all cost. However I would use an asynchronous connection, like sending an HTTP request to the server and then get a reply whenever the server feels like it.
If you need the server to reply to the client at some later time, but you don't know when, you could also look into the Google Cloud Messaging framework, which gives you a transparent and consistent way of sending small messages to your clients from your server.
You need to consider some things, when you're developing a mobile application.
A smartphone doesn't have endless amount of battery.
A smartphone's Internet connection is somewhat volatile and you will lose Internet connection at different times.
When you keep a direct connection to server all the time, your app keep sending keep-alive packets, which means you'll suck the phone dry pretty fast.
When the Internet connection is as unstable as it gets on mobile broadband, you will lose the connection sometimes and need to recover from this. So if you use TCP because you want to make sure your packets are received you get to resend the same packets a lot of times and so get a lot of overhead.
Also you might run in to threading problems on the server-side, if you open threads on the server on your own, which it sounds like. Let's say you have 200 clients connecting to the server at the same time. Each client has 1 thread open on the server. If the server needs to serve 200 different threads at the same time, this could be quite a performance consuming task for the server in the end and you will need to do a lot work on your own as well.
2. When you exit your application, you'll need to clean-up after you. This should be done in your onPause method of the Activity which is active.
This means, killing off all active threads (or at least interupting them), saving the state of your UI (if you need this) and flushing and closing whatever open connections to the server you have.
As far as using Threads goes, I would recommend using some of the build-in threading tools like Handlers or implementing the AsyncTask.
If you really think Thread is the way to go, I would definitely recommend using a Singleton pattern as a "manager" for your threading.
This manager would control your threads, so you don't end up with more than one Thread talking to the server at any given time, even though you're in another part of the application.
As far as the Application class implementation goes, take a look at the Application class documentation:
Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created.
There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way.
So keeping away from implementing your own Application class is recommended, however if you let one of your Activities initialize your own Singleton class for managing the Threads and connections you might (just might) run into trouble, because the initialization of the singleton might "bind" to the specific Activity and so if the specific Activity is removed from the screen and paused it might be killed and so the singleton might be killed as well. So initializing the singleton inside your Application implementation might deem useful.
Sorry for the wall of text, but your question is quite "open-ended", so I've tried to give you a somewhat open-ended question - hope it helps ;-)