3

I have two designs for an instant message program that I'm writting in Java

The first idea uses 2 separate threads. The first thread overlooks the gui and sends out the instant message data through writing to a blocking socket. The 2nd thread uses another blocking socket to monitor for incoming packets from the friend. I'm not certain if using threads is the best way to approach this problem, but I find it to be easier to deal with than using non-blocking socketchannels.

The 2nd design that I have is to use non-blocking socket channels in one thread which will occasionally check to see if there is incoming or outgoing data. The nice thing about this design is that I don't have to worry about resource sharing among threads, but I'm not sure if its more efficient.

Honestly, all I really care about is making a program that runs smoothly and efficiently. What do you think would be a more efficient and easier design to build? I'm just playing around so I have no experience in building efficient and powerful client/server programs other than what my senses tell me.

Dr.Knowitall
  • 10,080
  • 23
  • 82
  • 133
  • I think its appropriate to take efficiency into account. I don't know of any resources that give consideration to efficient client-server design. Learning to use threads and sockets is too easy. Writing something that works is no brainer, but designing something that works flawlessly, quickly, and efficiently is an art into itself. – Dr.Knowitall Dec 27 '12 at 05:19

2 Answers2

5

Long time ago I made a software, which had the chat module with TCP/IP : sockets.

At the beginning for each client it was 2 Thread: the ReaderThread and the WriterThread. It wasn't enough, because the clients get disconnected. I needed to make an InactivityChecker thread too, because the reader wasn't able to detect disconnections at server side, and the writer only when he had message. 3 thread / client is a bit waste of the resources, but it can go up to 5000 simultaneous clients!! -it will eat your processors with context switching! Also has must take care of the maximum port numbers opened.

If you would like to allow more than 65525/2 clients "simultaneously" for technical reasons the asynchron way is the only was to go.

  • Your input is much appreciated. I've decided to go with a non-blocking server/client model. I had not taken into account waiting for the client to respond and that would be a bug open to denial of service. I believe the best model for me is to create a dedicated thread for listening to all incoming text from multiple firends. This will then send the information to the correct window of my friend, and even if I had a disconnected friend ... I wouldn't waste resources blocking on that call. I may even consider putting in a time out counter for a particular connection. – Dr.Knowitall Dec 27 '12 at 05:42
  • any of the blocking / not blocking design has advantage and disadvantage. The decision should be made always on context: where it will be used? - a homework, a hobby chat with friends, or a high load server. How much time, money do you want to invest in developing, testing, maintening the code, if needed at all. Ho many user will use, how often and so on. Some ppl will choose solution A, because they don't know enough from solution B. That's why can be a good solution of Alexei: just pick one and do it, if you know what to expect from that solution than is even better :) –  Dec 27 '12 at 05:54
  • Thank you, I think with your help I've developed a good solution I will implement. Its good to get a second eye on matters. – Dr.Knowitall Dec 27 '12 at 07:53
2

You are writing a chat program, don't you? In this case, the amount of data sent ad received is so small that you should not care about efficiency. Do it the way which is easier to program. I would chose to send data directly in the UI thread (write latency should not be large) and read data in a separate thread, which then sends received data to the UI thread using well-known methods. In both directions, using plain blocking socket is the simpliest approach.

Alexei Kaigorodov
  • 13,189
  • 1
  • 21
  • 38
  • +1. almost right except the: " send data directly in the UI thread" I will never, ever make again such like that. Even for 1 byte :) –  Dec 27 '12 at 05:45
  • Well, I'm actually designing a client that will use a variety of services ... not just text. For now I'm only dealing with the instant message aspect of the program, but this will likely become my own version of skype which will incorporate video/voice/and file transfer. Not to mention that it must transfer data between groups and many other friends simultaneously. Thats why I'm designing an efficient client-server from the ground up. I'm hoping to circumvent many of the problems that come with sloppy solutions. – Dr.Knowitall Dec 27 '12 at 07:51
  • I see only one plus of a non-blocking solution: not wasting space for threads. It matters for servers which keep thousands of connections, but for clients, which deal with a few connections only, it has no sense. Traditional blocking socket I/O is easier to program, to debug, and at last, it is faster. – Alexei Kaigorodov Dec 27 '12 at 12:56
  • You've managed to change my mind. You are right, it's only the client side that I'm working on for now and blocking sockets really are much easier to deal with even if it creates more threads. I can't imagine more than 3 or 4 clients connected to each other at one time. – Dr.Knowitall Dec 28 '12 at 02:07