[jboss-jira] [JBoss JIRA] (JGRP-1476) TCP: double-write is useless as output stream is buffered

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1476:
---------------------------

    Description: 
[Stanimir Simeonoff]

Now I'd like to report a relatively minor issue w/ TCPConnection.doSend and
'double-writes' per Unix Network Programming.
The body of the method is like follows:

{code}
        private void doSend(byte[] data, int offset, int length) throws
Exception {
            // we're using 'double-writes', sending the buffer to the
destination in 2 pieces. this would
            // ensure that, if the peer closed the connection while we were
idle, we would get an exception.
            // this won't happen if we use a single write (see Stevens, ch.
5.13).

            out.writeInt(length); // write the length of the data buffer
first
            *Util.doubleWrite(data, offset, length, out)*;// should be
just: out.write(data, offset, length);
            out.flush(); // may not be very efficient (but safe)
        }
{code}

The comment claims it uses 'double-writes' in order to capture a missing
connection close by the peer. Firstly, that misled me there were not
buffers involved, so it writes straight to the socket output stream but in
that case out.flush() is a NOP.
If that was the case there would be at least 6 packets(!) per message (when
naggling is disabled) - 4 separate calls to each byte of writeInt and then
2 more for Util.doubleWrite. That looked very suspicious and must have been
caught, so I  took a look at the out declaration and it's buffered via
BufferedOutputStream with default 8k buf size which is the better size on
linux (buffers less than 8k are allocated on the stack instead of
malloc/free).
However that means doubleWrite is totally not useful as the output is
buffered anyways.
Also double-write is not useful if there is a reading/polling as RST would
be caught immediately, closing the connection. It's useful only if there is
no reading on the socket and that's quite a corner case.


  was:
[Stanimir Simeonoff]

Now I'd like to report a relatively minor issue w/ TCPConnection.doSend and
'double-writes' per Unix Network Programming.
The body of the method is like follows:

        private void doSend(byte[] data, int offset, int length) throws
Exception {
            // we're using 'double-writes', sending the buffer to the
destination in 2 pieces. this would
            // ensure that, if the peer closed the connection while we were
idle, we would get an exception.
            // this won't happen if we use a single write (see Stevens, ch.
5.13).

            out.writeInt(length); // write the length of the data buffer
first
            *Util.doubleWrite(data, offset, length, out)*;// should be
just: out.write(data, offset, length);
            out.flush(); // may not be very efficient (but safe)
        }

The comment claims it uses 'double-writes' in order to capture a missing
connection close by the peer. Firstly, that misled me there were not
buffers involved, so it writes straight to the socket output stream but in
that case out.flush() is a NOP.
If that was the case there would be at least 6 packets(!) per message (when
naggling is disabled) - 4 separate calls to each byte of writeInt and then
2 more for Util.doubleWrite. That looked very suspicious and must have been
caught, so I  took a look at the out declaration and it's buffered via
BufferedOutputStream with default 8k buf size which is the better size on
linux (buffers less than 8k are allocated on the stack instead of
malloc/free).
However that means doubleWrite is totally not useful as the output is
buffered anyways.
Also double-write is not useful if there is a reading/polling as RST would
be caught immediately, closing the connection. It's useful only if there is
no reading on the socket and that's quite a corner case.



    
> TCP: double-write is useless as output stream is buffered
> ---------------------------------------------------------
>
>                 Key: JGRP-1476
>                 URL: https://issues.jboss.org/browse/JGRP-1476
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.0.11, 3.1
>
>
> [Stanimir Simeonoff]
> Now I'd like to report a relatively minor issue w/ TCPConnection.doSend and
> 'double-writes' per Unix Network Programming.
> The body of the method is like follows:
> {code}
>         private void doSend(byte[] data, int offset, int length) throws
> Exception {
>             // we're using 'double-writes', sending the buffer to the
> destination in 2 pieces. this would
>             // ensure that, if the peer closed the connection while we were
> idle, we would get an exception.
>             // this won't happen if we use a single write (see Stevens, ch.
> 5.13).
>             out.writeInt(length); // write the length of the data buffer
> first
>             *Util.doubleWrite(data, offset, length, out)*;// should be
> just: out.write(data, offset, length);
>             out.flush(); // may not be very efficient (but safe)
>         }
> {code}
> The comment claims it uses 'double-writes' in order to capture a missing
> connection close by the peer. Firstly, that misled me there were not
> buffers involved, so it writes straight to the socket output stream but in
> that case out.flush() is a NOP.
> If that was the case there would be at least 6 packets(!) per message (when
> naggling is disabled) - 4 separate calls to each byte of writeInt and then
> 2 more for Util.doubleWrite. That looked very suspicious and must have been
> caught, so I  took a look at the out declaration and it's buffered via
> BufferedOutputStream with default 8k buf size which is the better size on
> linux (buffers less than 8k are allocated on the stack instead of
> malloc/free).
> However that means doubleWrite is totally not useful as the output is
> buffered anyways.
> Also double-write is not useful if there is a reading/polling as RST would
> be caught immediately, closing the connection. It's useful only if there is
> no reading on the socket and that's quite a corner case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira