Non destructive read of socket
in [Java Programming]
|
From: EJP on 7 Oct 2009 01:06 Peter Duniho wrote: > I had just assumed those methods wouldn't be supported on the > InputStream from a Socket. Are you sure they are? I'm sure they're *not*! But they are supported by BufferedInputStream, which he should be using anyway round a socket input stream. > The whole scheme has "bad idea" written all over it anyway I agree.
From: Mark on 7 Oct 2009 04:47 On Tue, 06 Oct 2009 10:24:59 -0700, Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> wrote: >Mark wrote: >> Is it possible to do a non-destructive read on a socket in Java? I >> want the functionality similar to the C library recv() using the >> MSG_PEEK flag. >> >> More information: >> I am implementing an API in Java which needs to send a "are you alive" >> application message over a socket. In reply it will get a "I am >> alive" message. However there may be another type of message already >> waiting which the API must not read. The presence of any message will >> be enough for the API call to succeed. The "I am alive" message can >> just be discarded if it is read later. >> >> I realize I could buffer the messages internally, but I would prefer >> to avoid this if possible owning to the risk of losing a message if >> the application is terminated. >> >Rather than either of those, why not use a message dispatcher that reads >any available message, and dispatches it accordingly, including the "I >am alive" message. The problem is that there may not be anything that can consume some types of message at that time. The API is defined this way. For example there are API methods defined, including: test() - Send a keepalive message and peek into the tcp/ip buffer to see if there is a response. get() - Read an application message (if present). If the consumer calls test() then there is nothing to handle an application message. >Alternatively, I think you can set TCP_KEEPALIVE on >the socket, which will handle that at the TCP protocol level, so you >don't have to worry about it at the application protocol level. TCP_KEEPALIVE is different and does not detect all kinds of connection problems. I don't have the authority to start changing the protocol. I just have to implement it.
From: Mark on 7 Oct 2009 05:59 On Wed, 07 Oct 2009 05:06:59 GMT, EJP <esmond.not.pitt(a)not.bigpond.com> wrote: >Peter Duniho wrote: >> I had just assumed those methods wouldn't be supported on the >> InputStream from a Socket. Are you sure they are? > >I'm sure they're *not*! But they are supported by BufferedInputStream, >which he should be using anyway round a socket input stream. Why "should" I be using a BufferedInputStream? I am not currently using Streams at all btw.
From: Andreas Leitgeb on 7 Oct 2009 07:36 Mark <i(a)dontgetlotsofspamanymore.net> wrote: > On Wed, 07 Oct 2009 05:06:59 GMT, EJP >>Peter Duniho wrote: >>> I had just assumed those methods wouldn't be supported on the >>> InputStream from a Socket. Are you sure they are? >> I'm sure they're *not*! But they are supported by BufferedInputStream, >> which he should be using anyway round a socket input stream. > Why "should" I be using a BufferedInputStream? I am not currently > using Streams at all btw. Please tell us, which API you really use for socket-I/O. Maybe we're all just on the wrong track thinking too much in terms of InputStreams. You also wrote that you didn't like buffering, because of some potential loss in case of application termination... I wonder what other mechanism you use to continue using the socket if your app really crashes. In my experience, a crashing app always means the socket is closed, and all remaining data somehow lost, no matter if buffered or not. But the socket-API you use might perhaps work around that... And then perhaps, the socket-API you use may afterall have some peek-feature already...
From: Mark on 7 Oct 2009 08:14
On 07 Oct 2009 11:36:17 GMT, Andreas Leitgeb <avl(a)gamma.logic.tuwien.ac.at> wrote: >Mark <i(a)dontgetlotsofspamanymore.net> wrote: >> On Wed, 07 Oct 2009 05:06:59 GMT, EJP >>>Peter Duniho wrote: >>>> I had just assumed those methods wouldn't be supported on the >>>> InputStream from a Socket. Are you sure they are? >>> I'm sure they're *not*! But they are supported by BufferedInputStream, >>> which he should be using anyway round a socket input stream. >> Why "should" I be using a BufferedInputStream? I am not currently >> using Streams at all btw. > >Please tell us, which API you really use for socket-I/O. >Maybe we're all just on the wrong track thinking too much >in terms of InputStreams. I am using SocketChannel.read() and SocketChannel.write() [non-blocking mode]. >You also wrote that you didn't like buffering, because of >some potential loss in case of application termination... >I wonder what other mechanism you use to continue using the >socket if your app really crashes. In my experience, a >crashing app always means the socket is closed, and all >remaining data somehow lost, no matter if buffered or not. >But the socket-API you use might perhaps work around that... >And then perhaps, the socket-API you use may afterall have >some peek-feature already... It's probably a minimal risk, I agree. I'm not sure in case of application crash whether the data contained in any kernel buffers would ever be acknowledged. |