Non destructive read of socket
in [Java Programming]
|
From: Daniel Pitts on 6 Oct 2009 13:24 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. 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. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Christian on 6 Oct 2009 17:41 Mark schrieb: > 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. > I think usual approach is to not read from the socket directly but use a java.io.PushbackInputStream where you could push read bytes back in. Though I am not aware of any possible non destructive reading from sockets.. Christian
From: EJP on 6 Oct 2009 19:43 Peter Duniho wrote: > On Tue, 06 Oct 2009 01:58:33 -0700, Mark > <i(a)dontgetlotsofspamanymore.net> 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. > > AFAIK, no. java.io.InputStream.mark() and .reset(). java.io.PushbackInputStream.
From: Peter Duniho on 6 Oct 2009 19:56 On Tue, 06 Oct 2009 16:43:06 -0700, EJP <esmond.not.pitt(a)not.bigpond.com> wrote: > Peter Duniho wrote: >> On Tue, 06 Oct 2009 01:58:33 -0700, Mark >> <i(a)dontgetlotsofspamanymore.net> 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. >> AFAIK, no. > > java.io.InputStream.mark() and .reset(). I had just assumed those methods wouldn't be supported on the InputStream from a Socket. Are you sure they are? > java.io.PushbackInputStream. Technically, that's not "a non-destructive read on a socket". It's simply a variation on the buffering the OP wants to avoid in the first place. The whole scheme has "bad idea" written all over it anyway, but I still think the literal answer to the question as asked is "no". Yes, there are work-arounds, but they don't operate at the socket level. Pete
From: Kevin McMurtrie on 7 Oct 2009 00:38
In article <c21mc51u8vktmemgdd5q4q80s41pqva879(a)4ax.com>, Mark <i(a)dontgetlotsofspamanymore.net> 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. It doesn't sound like that's going to work reliably. Data existing and data flowing aren't the same thing. I think what you need is a message dispatcher thread, or demultiplexer if you want to call it that, handling the stream. It will route heartbeats off to their handler and app data off to another handler. Being that it operates independently of app data streams, it will be able to identify exactly the last time and type of data that passed through. -- I won't see Goolge Groups replies because I must filter them as spam |