Working with NIO and non-NIO sockets
Hello,
Trying to write a network manager kind of program where the client initiates a number of connections to different servers. Need to manage these connections through the life time of the session ( time the client is connected to the server). The client connections originate from a single machine, the servers are geographically distributed and about 1 to 5 connections between each client and server.
I have tried and example NIO client/server application and it works fine. I have tried the KnockKnock client/server example it works. But when I try to use the NIO client with the multithreaded knockknock server, the socket connection goes through okay. However the data written to socket channel on the client(NIO) side doesn't seem to reach the server(non-NIO). I can't change the servers since they already exist in the field. I am just trying to write the manager application to manage them.
Basically I am trying to avoid writing a multithreaded socket connection management program.
Thanks for any input.
[1050 byte] By [
Jay-Suna] at [2007-11-26 18:14:25]
# 2
Hi ejp,Thanks for looking into this. I have the exact example code (for NIO) as in the following link. http://rox-xmlrpc.sourceforge.net/niotut/index.htmlThe code is at the end of the page. I am using the client part of the code.Thanks for your
# 3
Not the greatest NIO code. The author seems unaware that closing a channel also cancels all its selection keys so he laboriously programs both operations every time he needs to close the channel. His discussion of OP_CONNECT makes little sense: the important point is that OP_CONNECT is only used in the connection phase and OP_WRITE is only used in the connected phase.
His code registers the channel for OP_WRITE as soon as the connection completes, when there is no pending data to write. This will just cause the selector to spin uselessly doing nothing. The channel should be registered with zero interest-ops and OP_WRITE should be registered when there is something to write, i.e. during the send() operation; and it should be deregistered when the write has completed successfully and there is no more data to write.
ejpa at 2007-7-9 5:47:49 >
