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. 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). 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. 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.
Wim
| Kenneth Pouncey <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 28/06/2005 14:27
|
|
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
