This post originated from an RSS feed registered with Java Buzz
by Marc Logemann.
Original Post: Netversys@Work: sockets
Feed Title: Logemann Blog
Feed URL: http://www.logemann.org/blojsom/blog/default/?flavor=rss2
Feed Description: Marc's thoughts on Java and more
I decided to write about technical issues with our poduct on a regular basis. The entries are marked with "Netversys@Work" in the subject followed by the real topic. Of course its not too much different to my other blog entries since its all about java. The only difference is that i show specific problems having with such a product and how we approach them. In fact i also blogged before about technical details and implementations of our product...
Network programming is a huge area of our product since it must handle a lot of TCPIP connections to printers, balances, third party servers and all the common stuff like SOAP and HTTP and the likes. With all those web networking thingies like SOAP, you dont need to know anything about networking, but when you want to feed your printer with raw printer data or if you wanna speak with an electronical balance with its custom protocol, you need some basic understanding how networking works in java. Here is a little sketch how the system looks like:
In the middle we have the server application. In fact its not a stand-alone server but a JavaEE (i hate this new acronym) based application. As you can see many people are working at their logistic workplaces with printers and balances. We are not only managing all printers from within our software, we are also speaking with them directly.
So far we used SocketChannels quite a lot for communicating with the devices. Of course a socketChannel is not doing the real work because Socket still does, but back then i used SocketChannel because i really wanted to program with NIO :) But unfortunately it turned out that working directly with Socket is more convenient for our specific problem.
We have no real non-blocking use case and as far as i see it, its a little bit unconvenient to use SocketChannel in blocking mode together with timeouts. A simple example: You want to connect to a printer but you are not sure if he is responding on socket connect. With Socket, you can easily supply a timeout value in its connect() method, while with SocketChannel (which works also in blocking mode by default) this is not possible. In fact you have to code your timeout yourself by using connect() together with finishConnect() and some handcrafted loop.
So the strength of SocketChannel is really the non-blocking part (surprise surprise) especially with the mentioned methods. Just dont forget call configureBlocking(true) to start in non-blocking mode. But this was only one part where we needed to improve. Another problem is the unreliability of a third party server of a big logistics company. Sometimes it happens that this server stops communicating, it then accepts the custom protocol via socket but doesnt reply to any messages.
So far we have not used any timeouts on our sockets because we thought that we can trust our partner server but it seems its always a good idea to define timeouts and react on them. So socket.setSoTimeout(x) was our new friend. It interrupts the blocked read() method of the underlying stream at the defined timeout interval and one can do certain actions. This is a great way to implement failover techniques. Our customer server just received a second server from its logistic carrier for scenarios like these. Now our product can react on those problems and can disable the faulted machine if a timeouts occurs. The subsequent socket requests are then directed to the other machine. In a perfect world we wouldnt need that right?
Previous Topic
