CODEWITHSUNDEEP
javamultithreadingudp
Ólafur Waage
Ólafur Waage

Reputation: 69981

How to design a threaded UDP client/server in Java?

I'm just looking for some insight into program design, since I'm not that experienced with threads.

Currently programming a little client. You can specify if that client is the "server" or "client" and it will create the protocols in the correct manner.

I do a little handshake between them (a syn, ack, synack sort of thing) and then start the network thread.

I have the main thread, who has an infinite while loop and does two things.

  1. Adds a message to a "toSend" queue.
  2. Pulls in all the messages from the "received" queue and prints them.

The network thread has an infinite while loop that does two things.

  1. Pulls in all the messages from the "toSend" queue and sends them.
  2. Adds a message to the "received" queue (that was fetched).

The queues are currently ArrayBlockingQueue<String>(1000)

My question is the following:

Is this towards a good design of a network thread? Are there any gotchas I need to handle?

Currently I've had an issue where one of the threads (the main thread) is filling the "toSend" queue even before the network thread has a chance to send even one message. I've "handled" this by making the main thread do some work that blocks (I/O).

Upvotes: 1

Views: 1966

Answers (4)

user207421
user207421

Reputation: 310840

The 'toSend' queue is pointless. Just have everybody send directly via the socket.

Upvotes: 0

GETah
GETah

Reputation: 21409

I have been working on UDP/TCP real time systems for more than 4 years now. Your question has a lot of sense. In my humble opinion, the Netty framework is a good way to go but a bit heavy.

I am using the exact same design that you mentioned and have seen no issues with it so far.

Regards,

Upvotes: 1

Peter Tillemans
Peter Tillemans

Reputation: 35331

Personally I think that handling UDP networking is best done using a single threaded, event driven programming style, rather than using threads. It is stateless anyhow, so it makes little sense trying to track the state in a thread.

Things like timeouts are easily handled with timers adding events to the event queue.

This effectively sidesteps all the synchronisation issues.

Upvotes: 1

Thor
Thor

Reputation: 6656

It seems like you are re-inventing the wheel and are struggling with issues others have solved (and most probably with an optimized solution) before, please take a look at Netty:

The Netty project is an effort to provide an asynchronous event-driven network application framework and tools for rapid development of maintainable high performance & high scalability protocol servers & clients.

There is an example for an broadcast UDP/IP client and server.

Upvotes: 4

Related Questions