Socket Buffered*putStream Threads and Full-duplex communication

Discussion in 'Java' started by Richard Maher, Mar 16, 2010.

  1. Hi,

    I'm sure I asked a similar question here before but couldn't find it -
    sorry.

    Can someone please confirm that for a given Socket with a
    BufferedInputStream "in" and a BufferedOutputStream "out", I can have one
    thread T1 executing a series of out.write()s followed by an out.flush()
    without explicit locking or synchronizing that will in noway interfere with
    another Thread T2 that is happily performing one (or more until we get "n"
    bytes) in.reads?

    IOW, one T1 is sending messages as it likes to a remote server and T2 is
    processing the response messages. I want this all to happen in parallel and
    without explicit thread-synching or lock/mutexing. Is that architecturally
    sound given the classes that I am using?

    Cheers Richard Maher

    PS. For the sake of argument please assume that T1 is sending random numbers
    and T2 is just doing System.out.println() i.e pretend the reader and writer
    are completely independent.
     
    Richard Maher, Mar 16, 2010
    #1
    1. Advertising

  2. Hi Thomas,

    "Thomas Pornin" <> wrote in message
    news:4b9f9a05$0$22008$...
    > According to Richard Maher <>:
    > > Can someone please confirm that for a given Socket with a
    > > BufferedInputStream "in" and a BufferedOutputStream "out", I can have
    > > one thread T1 executing a series of out.write()s followed by an
    > > out.flush() without explicit locking or synchronizing that will in
    > > noway interfere with another Thread T2 that is happily performing one
    > > (or more until we get "n" bytes) in.reads?

    >
    > I can confirm. It is true without the buffered streams as well. The two
    > streams associated with a socket are independent from each other, save
    > for what happens upon closing either (or the socket itself). But
    > explicit synchronization is not needed either for that anyway.
    >
    >
    > > IOW, one T1 is sending messages as it likes to a remote server and T2
    > > is processing the response messages. I want this all to happen in
    > > parallel and without explicit thread-synching or lock/mutexing. Is
    > > that architecturally sound given the classes that I am using?

    >
    > It is actually sounder than many other architectures, if data may
    > be transmitted in both directions simultaneously.
    >
    >
    > > PS. For the sake of argument please assume that T1 is sending random
    > > numbers and T2 is just doing System.out.println() i.e pretend the
    > > reader and writer are completely independent.

    >
    > If reader and writer are _not_ completely independent, then the problem
    > becomes more complex. Depending on how they interact. One possible
    > interaction being on the remote side of the socket, of course. An
    > example is that of a HTTP client. Theoretically, the HTTP client may
    > send several requests in a row, asynchronously reading the responses,
    > but each response corresponds to one request, in due order. The client
    > must match requests and responses and there lies potential trouble.
    > Fortunately, the JVM comes with a HTTP client which already does all
    > that hard work.


    Thanks for confirming that for me.

    >
    > There is a subliminal message here: maybe you should try to use HTTP
    > as a transport mechanism ? Sun's JVM already comes with an HTTP client
    > _and_ an HTTP server. The HTTP client uses java.net.URL. For the HTTP
    > server, see:
    >

    http://java.sun.com/javase/6/docs/j...c/com/sun/net/httpserver/package-summary.html
    >
    >


    No a *signle*, secure, authenticated, connection-oriented, context-rich
    protocol will be just fine thanks.

    > --Thomas Pornin


    Cheers Richard Maher

    PS. For those with a love-affair for HTTP and the school of thought that
    says "Hey, I reakon BSD(ish) TCP/IP Sockets would be much better implemented
    over HTTP" then you'll probably love the bollocks the HTML5 people have come
    up with :-(

    See http://cometdaily.com/2010/03/02/is-websocket-chat-simple/ for just some
    issues.

    You just can't make a silk middleware-backbone out of a pig's http!
     
    Richard Maher, Mar 16, 2010
    #2
    1. Advertising

  3. Richard Maher

    EJP Guest

    On 17/03/2010 1:47 AM, Thomas Pornin wrote:
    > I can confirm. It is true without the buffered streams as well. The two
    > streams associated with a socket are independent from each other, save
    > for what happens upon closing either (or the socket itself). But
    > explicit synchronization is not needed either for that anyway.


    Qualification: if you started with a SocketChannel and got the streams
    via Channels.newInput/OutputStream, the input and output streams are
    synchronized internally for some reason, so problems can occur if you
    try to use them in full-duplex mode. However if you started with a
    Socket you are OK.
     
    EJP, Mar 17, 2010
    #3
  4. Hi EJP,

    "EJP" <> wrote in message
    news:65Vnn.13412$...
    > On 17/03/2010 1:47 AM, Thomas Pornin wrote:
    > > I can confirm. It is true without the buffered streams as well. The two
    > > streams associated with a socket are independent from each other, save
    > > for what happens upon closing either (or the socket itself). But
    > > explicit synchronization is not needed either for that anyway.

    >
    > Qualification: if you started with a SocketChannel and got the streams
    > via Channels.newInput/OutputStream, the input and output streams are
    > synchronized internally for some reason, so problems can occur if you
    > try to use them in full-duplex mode. However if you started with a
    > Socket you are OK.


    Thanks for the heads-up about SocketChannels but we're using plain Sockets
    so looks like we should be ok.

    Thanks again

    Cheers Richard Maher
     
    Richard Maher, Mar 17, 2010
    #4
  5. Richard Maher

    hiwa Guest

    On Mar 17, 7:50 pm, "Richard Maher" <>
    wrote:
    > Hi EJP,
    >
    > "EJP" <> wrote in message
    >
    > news:65Vnn.13412$...
    >
    > > On 17/03/2010 1:47 AM, Thomas Pornin wrote:
    > > > I can confirm. It is true without the buffered streams as well. The two
    > > > streams associated with a socket are independent from each other, save
    > > > for what happens upon closing either (or the socket itself). But
    > > > explicit synchronization is not needed either for that anyway.

    >
    > > Qualification: if you started with a SocketChannel and got the streams
    > > via Channels.newInput/OutputStream, the input and output streams are
    > > synchronized internally for some reason, so problems can occur if you
    > > try to use them in full-duplex mode. However if you started with a
    > > Socket you are OK.

    >
    > Thanks for the heads-up about SocketChannels but we're using plain Sockets
    > so looks like we should be ok.
    >
    > Thanks again
    >
    > Cheers Richard Maher


    Hi EJP
    We'd like you reviving your telekinesis.au site.
    We need some files there to see regarding your FNiJ book.
    hiwa
     
    hiwa, Mar 17, 2010
    #5
    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. cyberco

    Splitting a full-duplex socket

    cyberco, Dec 22, 2004, in forum: Java
    Replies:
    31
    Views:
    6,885
  2. Stanislav Tsukrov

    MIDP 2.0 SocketConnection - full duplex

    Stanislav Tsukrov, Mar 5, 2006, in forum: Java
    Replies:
    0
    Views:
    441
    Stanislav Tsukrov
    Mar 5, 2006
  3. Replies:
    3
    Views:
    695
    Greg Ewing
    Mar 31, 2005
  4. Dara Durum
    Replies:
    5
    Views:
    336
    Dara Durum
    Jun 26, 2006
  5. Replies:
    9
    Views:
    687
    Michael Wojcik
    Aug 23, 2005
Loading...

Share This Page