Re: Non destructive read of socket

Discussion in 'Java' started by Kevin McMurtrie, Oct 7, 2009.

  1. In article <>,
    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.


    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
    Kevin McMurtrie, Oct 7, 2009
    #1
    1. Advertising

  2. Kevin McMurtrie

    Gilbert Guest

    Kevin McMurtrie wrote:

    > In article <>,


    >
    > 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.


    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. What I
    think I'd like to be able to do is to register a listener
    for a specific message id. Is there anything available that
    I could extend or would I have to roll my own

    Regards
    Gilbert, Oct 7, 2009
    #2
    1. Advertising

  3. Kevin McMurtrie

    Tom Anderson Guest

    On Thu, 8 Oct 2009, Gilbert wrote:

    > Kevin McMurtrie wrote:
    >
    >> 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.

    >
    > 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. What I think I'd like to be able to do is to
    > register a listener for a specific message id. Is there anything
    > available that I could extend or would I have to roll my own


    I can't think of anything. But this isn't hard:

    interface MessageHandler {
    public void handle(int messageType, InputStream in) throws IOException;
    }

    class MessageDispatcher implements Runnable {
    private final InputStream in;
    private final Map<Integer, MessageHandler> handlers;

    public void run() {
    // you'll need some exception handling here
    // and some thread control somewhere
    while (true) {
    int messageType = in.read();
    if (messageType == -1) throw new EOFException();
    MessageHandler handler = handlers.get(messageType);
    if (handler == null) throw new IOException("bad message type: " + messageType);
    handler.handle(messageType, in);
    }
    }
    }

    Instead of a map, you could use an array of length 256 (or less), keyed by
    the byte. Or you could have an enum of message types, turn the message
    type byte into an enum value, then use an EnumMap.

    tom

    --
    This is the best kind of weird. It can make a corpse laugh back to
    death. -- feedmepaper
    Tom Anderson, Oct 8, 2009
    #3
  4. Gilbert <> 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 :)
    Andreas Leitgeb, Oct 8, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ville Vainio
    Replies:
    11
    Views:
    476
    Ville Vainio
    Apr 6, 2005
  2. Daniel Pitts

    Re: Non destructive read of socket

    Daniel Pitts, Oct 6, 2009, in forum: Java
    Replies:
    1
    Views:
    404
    Tom Anderson
    Oct 7, 2009
  3. EJP
    Replies:
    9
    Views:
    452
  4. Giles Bowkett
    Replies:
    13
    Views:
    241
    Jacob Fugal
    Mar 15, 2007
  5. Kyle Schmitt

    non-destructive option parser?

    Kyle Schmitt, Apr 24, 2008, in forum: Ruby
    Replies:
    2
    Views:
    101
    Kyle Schmitt
    Apr 25, 2008
Loading...

Share This Page