rename the attached .txt file as a .java file.
its depends on junit and commons-logging
and i rammed all the classes into one file for posting.
the server test case just opens up a multicast socket and writes to it, 10 messages in a loop here. the client test starts listening for (also 10 ) test messages. clearly we wouldn't want the real clients to expect the finite number of messages, i just do this to demonstrate the multicast socket writing and reading stuff, though in this case it currently assumes the same single message object is always going to be sent, and from one server sending onto the multicast channel, and that there are no lost packets. in the general case, more than one node could be sending different messages into the same channel, and that is likely more complicated than you need here for the poker server anyway.
you should be able to launch the individual test methods such as inside eclipse. start off the client(s) first, then the server. there are methods to do a single message, and tests to launch a thread to do the receive messages in a loop.
that chunking stream stuff is one of my pet experimental things to conveniently allow us to just "send an object" or "receive an object", instead of having to think about stuffing the message within the maximum packet size. the Java datagram socket is 'nice' enough to silently discard and not complain very much if the amount of data to be sent or read happens to exceed the maximum datagram packet size. I like to just have all the packets within the MTU of the network link, so as to increase the chances of all the packets making it and not losing anything by having the data [from a single datagram write] split up over more than one ethernet packet..
you will see i just create anonymous instances of these chunking streams and implement the get/set content methods which internally do the DatagramPacket work.
|