NIO: DatagramChannel/UDP, Testing-Client and architectural question
hello,
i just finished reading and working through java's nio-package and coded my first nio-tcp-server which works quite neatly.
now i have to extend the functionality to udp but i dont get this DatagramChannel, as you can't "accept" connections in tcp-style.
does anybody have a link to a good NIO-UDP-Tutorial and some utility to send udp-datagrams (pref. windows) ?
the second 'architectural' question:
i have to implement something representing an industrial facility, which has many processes running and shall send process-data over TCP,UDP and COM/Serial. goal is to visualize this data with some smart components.
as COM/Serial are blocking-operations, and NIO is not: shall i create two threads, one managing COM and one managing all TCP/UDP-connections?
shall i manage the TCP/UDP-NIO-Stuff with multiple threads?
the NIO-tutorials/books mention that all examples are a bit too simplistic and in a "real-world-app" you would use some multithreaded-architecture to handle the NIO-connections.... why?
thanks a lot,
kai
1. The architecture of a TCP server is that you have a listening socket and you accept connections in the form of accepted Sockets, each of which represents a connected client.
The architecture of a UDP server is quite different. First, there are no connections at all, there are just datagram packets which arrive. So you are forced into a stateless protocol design, which IMO is a benefit anyway. From the sockets point of view a UDP server only has the one DatagramSocket and it carries out all its sending/receiving via that. The 'state' of the request is really embodied in the DatagramPacket class, which contains the request and where it came from, so the reply can actually be written into the same DatagramPacket and sent back. These things are also quite nice to put on queues if that is your bent.
2. You can do all the TCP/UDP NIO in a single thread and there are great benefits in doing that, such as no syncrhonization, as long as your responses can be generated quickly without blocking (e.g. on database lookups). (Otherwise you are into work queues and worker threads and ann that.)
You will need a thread per COM connection and per any other connection that is blocking.
ejpa at 2007-7-15 4:04:47 >
I've never explored this in any detail, but you can use multiple selectors, each in their own thread, for purposes like servicing different selection groups with different priorities, or perhaps allocating them to different back-end services.
ejpa at 2007-7-15 4:04:47 >
