Wim Quoting [EMAIL PROTECTED]:
> Kenneth, > > the switch would watch all channels for incoming or outgoing > communication. It would capture one stream of bytes and handle it. The > handling can be either processing the data itself or either dispatching > the data and continue listening. Yes that is how I understand it as well. It is the association of a read/write SocketChannel to a specific terminal that I am having trouble with. >As I unserstand correctly what you have > implemented is that for each emulator session you have a thread that > listens on the sockets waiting for data to come in (this as a matter a > fact is definition of typical synchronuous IO). Correct. It is a defintion of a typical synchronous IO connection. >When data arrives parse it > and wrap the bytes in stream packet objects or commands or something. What > NIO allows you to do is have one thread listen on all sockects/channels > and get triggered when data arrives on one socket. It could then dispatch > it as it does right now and continue listening. Hummmm need to think about this. Sounds simple but again the dispatching to the correct terminal hits me. >In the meantime on another > channel data could have arrived to be dispatched etc. As mostly for all > sessions there will be one very active, this scenario would perfectly work > without much performance loss, but with much less resources. I guess I could keep a list of all the sockets and do a search for the channel to find the correct terminal to send it to. Maybe that is what you mean. 1. Got something. 2. Look up the correct terminal instance (somehow) 3. Add the byte stream to it's queue to be handled. 4. return to main incoming thread. This is simplistic at it's best because there are also partial streams to be considered where one datastream overlaps multple incoming buffers. that will have to be kept straight as well. Is the above what you are thinking as well Wim? Cuts down on one thread per terminal except for the first terminal connect. Regards Kenneth > > Wim > > > > > > Kenneth Pouncey <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 28/06/2005 14:27 > Please respond to > tn5250j-general@lists.sourceforge.net > > > To > tn5250j-general@lists.sourceforge.net > cc > > Subject > Re: [Tn5250j-general] JDK version > > > > > > > Wim > > Thanks for the feedback. > > > Quoting [EMAIL PROTECTED]: > > > Hello Kenneth, > > > > I remembered Patrick asking this upgrade, but not from the point of > using > > 'new' technologies like nio, I think. Rather to cleanout 1.3 specific > code > > and integrating new APIs. Probably Swing related APIs most of the times. > > Ahhh. Boy misunderstood that then. > > > > > As I understood NIO it mostly helps for doing async io indeed but also > > allow better scalable IO. This is however more server oriented than this > > > client side project is. > > Yes correct the same thing as I thought. > > >So this would not directly benefit us. However a > > lot of the multithreading things that are in the code base right, would > be > > gone. You wouldn't have to start a comm-thread for every emulator but > use > > one thread on a channel as a switcher. As you mostly use one emulator > > session at the time, this wouldn't pose performance problems and do the > > same thing with less resources. > > Well this is what I have been thinking about when using asynchronous but > could > not see the benefit of the single thread issue. I say this because all > the > emulator instances can interact at different times not just in one and > only one. > > For instance I have a query running on one terminal and it updates the > screen > while I am on another terminal waiting for the other to finish. I can > still > work on the other terminals and the interaction is still going on in the > others. > There are also timing marks that are sent and heartbeat-keepalives that > still > have to be used between the other terminals as well. > > I apoligize for my blindnes for all those out there that understand the > asynchronous better than I do but do not see how to handle this situation > in the > channel switching code. Will this work? If it will then it is an option > for me > to continue with. I would really hate to tear all of that code apart > again just > to find out it will not work. Like I said have only used the asynchronous > in a > small server part but my mind will not wrap around putting this to use on > the > client side. > > Maybe I am not seeing the forest for the trees in front. > > Thanks for the feedback Wim. > > Regards > > Kenneth > > > > > HTH, > > Wim. > > > > > > > > > > > > Kenneth Pouncey <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 28/06/2005 11:44 > > Please respond to > > tn5250j-general@lists.sourceforge.net > > > > > > To > > tn5250j-general@lists.sourceforge.net > > cc > > > > Subject > > [Tn5250j-general] JDK version > > > > > > > > > > > > > > > > > > Hello all > > > > I remember a post, from Patrick I think, that was asking to move the > > emulator up > > to 1.4 and use some of the features for those greater than 1.3. > > > > I am assuming that would mean to use the NIO streams, channels and the > > such correct? > > > > If that is the case what would using the NIO help us achieve that can > not > > be > > done now? Would it be better? What would be the goal? > > > > I ask because after having used the NIO in a couple of small projects it > > > really > > only helps for asynchronous correct? We really use synchronous on the > > client > > side and really do not see any speed enhancment or anything like that > when > > using > > the synchronous model. > > > > If anyone suggests the asynchronous model for doing this could they tell > > > me why > > that would help. I do not see it but am open to learning the benefits > and > > the > > coding if it will help us reach a goal. > > > > Regards > > > > Kenneth > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > > from IBM. Find simple to follow Roadmaps, straightforward articles, > > informative Webcasts and more! Get everything you need to get up to > > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > > _______________________________________________ > > Tn5250j-general mailing list > > Tn5250j-general@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/tn5250j-general > > > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Tn5250j-general mailing list > Tn5250j-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tn5250j-general > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Tn5250j-general mailing list Tn5250j-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tn5250j-general
