Non destructive read of socket
in [Java Programming]
|
From: Andreas Leitgeb on 8 Oct 2009 06:48 Gilbert <nospam(a)nowhere.com> wrote: > That sounds like it could help with something I'm doing > reading messages from a serial port. There are about 20 > message types that require slightly different handling > depending on the message identifier byte. I don't really > want the message dispatcher to have to know about all > the different handlers and the "standard" listener pattern > means that all handlers receive all messages and ignore > those that they don't want which seems wasteful. You could also "daisy-chain" the listeners: first listener gets the message: if it knows it, it handles it, otherwise pass it on to next listener. If the message type is easily extractable, e.g. the 42 bits(*) starting with the 7th one, then make a HashMap, that maps the type (embedded into a Long) to the responsible listener, which must have been registered separately for each message-type that it is responsible for. > ... could extend or would I have to roll my own I think rolling your own is simple enough in this case. *: that's not a multiple of 8, but it's still "simple", in that one doesn't need to know each message exactly to be able to extract the type :-)
From: Andreas Leitgeb on 8 Oct 2009 07:19 Mark <i(a)dontgetlotsofspamanymore.invalid> wrote: >>> I am using SocketChannel.read() and SocketChannel.write() >>> [non-blocking mode]. >>So therefore the answer to your question is a combination of OP_READ and >> resetting ByteBuffer.position(). > I don't understand why there is a need to use a ByteBuffer. This > method should not be acutally reading any data. What happens, if the user of your lib doesn't read data for a long time, but requests aliveness of the party regularly? first time: good, there's unread stuff in the socket. second time: good, there's still unread stuff in the socket. ditto for the next 1000 times 1003rd time: good, there's still ... (although the party dropped the connection right after the 1st reply) You really need to read out the stuff, or you won't be able to tell old received data from new received data.
From: EJP on 8 Oct 2009 07:47 Mark wrote: > On Wed, 07 Oct 2009 23:27:24 GMT, EJP > <esmond.not.pitt(a)not.bigpond.com> wrote: > >> Mark wrote: >>> I am using SocketChannel.read() and SocketChannel.write() >>> [non-blocking mode]. >> So therefore the answer to your question is a combination of OP_READ and >> resetting ByteBuffer.position(). > > I don't understand why there is a need to use a ByteBuffer. This > method should not be acutally reading any data. I don't understand how you can use SocketChannel.read() without a ByteBuffer. Please explain.
From: Mark on 8 Oct 2009 10:31 On Thu, 08 Oct 2009 11:47:02 GMT, EJP <esmond.not.pitt(a)not.bigpond.com> wrote: >Mark wrote: >> On Wed, 07 Oct 2009 23:27:24 GMT, EJP >> <esmond.not.pitt(a)not.bigpond.com> wrote: >> >>> Mark wrote: >>>> I am using SocketChannel.read() and SocketChannel.write() >>>> [non-blocking mode]. >>> So therefore the answer to your question is a combination of OP_READ and >>> resetting ByteBuffer.position(). >> >> I don't understand why there is a need to use a ByteBuffer. This >> method should not be acutally reading any data. > >I don't understand how you can use SocketChannel.read() without a >ByteBuffer. Please explain. I use a ByteBuffer for the read, but this question was about detecting data available, not reading it. The context has been snipped. -- (\__/) M. (='.'=) Due to the amount of spam posted via googlegroups and (")_(") their inaction to the problem. I am blocking most articles posted from there. If you wish your postings to be seen by everyone you will need use a different method of posting. [Reply-to address valid until it is spammed.]
From: Mark on 8 Oct 2009 10:33
On 08 Oct 2009 11:19:47 GMT, Andreas Leitgeb <avl(a)gamma.logic.tuwien.ac.at> wrote: >Mark <i(a)dontgetlotsofspamanymore.invalid> wrote: >>>> I am using SocketChannel.read() and SocketChannel.write() >>>> [non-blocking mode]. >>>So therefore the answer to your question is a combination of OP_READ and >>> resetting ByteBuffer.position(). >> I don't understand why there is a need to use a ByteBuffer. This >> method should not be acutally reading any data. > >What happens, if the user of your lib doesn't read data for a long >time, but requests aliveness of the party regularly? > >first time: good, there's unread stuff in the socket. >second time: good, there's still unread stuff in the socket. >ditto for the next 1000 times >1003rd time: good, there's still ... > (although the party dropped the connection right after the 1st reply) > >You really need to read out the stuff, or you won't be able to >tell old received data from new received data. It is the reponsibility of the consumer of the API to use it correctly. This is how the whole thing was designed (not by me, I must add). -- (\__/) M. (='.'=) Due to the amount of spam posted via googlegroups and (")_(") their inaction to the problem. I am blocking most articles posted from there. If you wish your postings to be seen by everyone you will need use a different method of posting. [Reply-to address valid until it is spammed.] |