On Linux FC4 I have a non-blocking tcp server
used with select. I have been under the impression
that a zero length read should be taken as a
hang-up. I am testing with nc on a nearby
similar box:

echo -n 123 | nc 192.168.1.32 5000

I find that my server receives a zero length message
after the "123", before I respond. If, as a test, I
do not close the server socket in response to the
zero length message, my response is received by the
nc process.

Is this a bug or misuse of nc? A I misinterpreting
the zero length read? Is there something that I am
overlooking? A quick test with a simple home-grown
client does not manifest this problem.

Thanks for your .
Mike.

In article <pan.2006.03.16.18.46.05.657481@yahoo.com>,
Mike - EMAIL IGNORED <m_d_berger_1900@yahoo.com> wrote:

> On Linux FC4 I have a non-blocking tcp server
> used with select. I have been under the impression
> that a zero length read should be taken as a
> hang-up. I am testing with nc on a nearby

It's EOF, not a hangup. Each direction of a TCP connection is
independent -- you can send EOF in one direction, while continuing to
allow data in the other direction.

> similar box:
>
> echo -n 123 | nc 192.168.1.32 5000
>
> I find that my server receives a zero length message
> after the "123", before I respond. If, as a test, I
> do not close the server socket in response to the
> zero length message, my response is received by the
> nc process.

When nc reads EOF on its standard input, it sends a FIN on the
connection so the server will see the EOF.

If you need to send a response, you shouldn't close the socket until
after you've done it.

> Is this a bug or misuse of nc? A I misinterpreting
> the zero length read? Is there something that I am
> overlooking? A quick test with a simple home-grown
> client does not manifest this problem.

How does your home-grown client indicate that it's done sending data if
it doesn't close the connection? If you have a mechanism in the
application protocol (like newline delimiters, or sending a byte count),
a generic client nc can't be expected to know about this.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

On Thu, 16 Mar 2006 16:02:37 -0500, Barry Margolin wrote:

[...]
> When nc reads EOF on its standard input, it sends a FIN on the
> connection so the server will see the EOF.
>
> If you need to send a response, you shouldn't close the socket until
> after you've done it.
[...]

Thanks for this. A have modified my code accordingly, and
it works correctly. Is there a way I can send such a FIN
from the application layer, and still wait for responses,
or to I have to go to a lower layer to do this?

Mike.

In article <pan.2006.03.17.01.54.00.887535@yahoo.com>,
Mike - EMAIL IGNORED <m_d_berger_1900@yahoo.com> wrote:

> On Thu, 16 Mar 2006 16:02:37 -0500, Barry Margolin wrote:
>
> [...]
> > When nc reads EOF on its standard input, it sends a FIN on the
> > connection so the server will see the EOF.
> >
> > If you need to send a response, you shouldn't close the socket until
> > after you've done it.
> [...]
>
> Thanks for this. A have modified my code accordingly, and
> it works correctly. Is there a way I can send such a FIN
> from the application layer, and still wait for responses,
> or to I have to go to a lower layer to do this?

shutdown(SHUT_WR) sends a FIN without closing the socket.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

In article <barmar-0A0618.16023716032006@comcast.dca.giganews.com>, Barry Margolin <barmar@alum.mit.edu> writes:
> In article <pan.2006.03.16.18.46.05.657481@yahoo.com>,
> Mike - EMAIL IGNORED <m_d_berger_1900@yahoo.com> wrote:
>
> > echo -n 123 | nc 192.168.1.32 5000
> >
> > I find that my server receives a zero length message
> > after the "123", before I respond.
>
> When nc reads EOF on its standard input, it sends a FIN on the
> connection so the server will see the EOF.
>
> If you need to send a response, you shouldn't close the socket until
> after you've done it.

As a side note (Mike reports he's already fixed the problem in his
server), you can avoid closing nc's standard input when it's used
this way, if necessary, by continuing to read from stdin after the
echo command completes:

(echo -n 123; cat) | nc 192.168.1.32 5000

and enter the tty EOF character (usually ^D) if and when you need
to close stdin.

Obviously this is a Unix shell programming matter, not a TCP/IP one,
so further discussion should go to comp.unix.shell or similar.

--
Michael Wojcik michael.wojcik@microfocus.com

That's gotta be one of the principles behind reality. Accepting things
that are hard to comprehend, and leaving them that way. And bleeding.
Shooting and bleeding. -- Haruki Murakami (trans Philip Gabriel)