I have a server, using RTP 6.2.0 on a Winsystems PC104 pentium computer. I’m
using the ntp-tcpip.so stack. My recv call will, occaisionally, be flooded
by millions of 0 length messages. It seems to handle other messages, but
sluggishly. I only allow a single client to connect and I don’t think it is
sending the empty data messages because when I shut it down, the string of 0
length messages continues until I shut down the server process. At that
point, the syslogs of this condition immediately cease.
Is there any related known problem with the 6.2.0 TCP/IP stack? Any
suggestions on what to do to start troubleshooting this problem?
Thanks,
David Kuechenmeister
A read of 0 on a socket should be anticipated. It should be
interpreted as EOF (the other end closed the connection).
-seanb
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
I have a server, using RTP 6.2.0 on a Winsystems PC104 pentium computer. I’m
using the ntp-tcpip.so stack. My recv call will, occaisionally, be flooded
by millions of 0 length messages. It seems to handle other messages, but
sluggishly. I only allow a single client to connect and I don’t think it is
sending the empty data messages because when I shut it down, the string of 0
length messages continues until I shut down the server process. At that
point, the syslogs of this condition immediately cease.
Is there any related known problem with the 6.2.0 TCP/IP stack? Any
suggestions on what to do to start troubleshooting this problem?
Thanks,
David Kuechenmeister
Thanks Sean,
That’s why I’m not treating it as an error, but I don’t see the 'broken
pipe" signal that usually appears with the client-side connection closing.
The other odd part is that after I kill off the client program, the recv
call continues to return with 0 data. Whether it really is the cause or not,
it appears as if the protocol stack is in a tight loop returning a
zero-length message. Surely, a client can’t reconnect and disconnect a
literal million times in less than a minute.
Regards,
David
“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:bksbdk$4h5$1@nntp.qnx.com…
A read of 0 on a socket should be anticipated. It should be
interpreted as EOF (the other end closed the connection).
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
I have a server, using RTP 6.2.0 on a Winsystems PC104 pentium computer.
I’m
using the ntp-tcpip.so stack. My recv call will, occaisionally, be
flooded
by millions of 0 length messages. It seems to handle other messages, but
sluggishly. I only allow a single client to connect and I don’t think it
is
sending the empty data messages because when I shut it down, the string
of 0
length messages continues until I shut down the server process. At that
point, the syslogs of this condition immediately cease.
Is there any related known problem with the 6.2.0 TCP/IP stack? Any
suggestions on what to do to start troubleshooting this problem?
Thanks,
David Kuechenmeister
SIGPIPE is generated on a write(). Most apps set signal(SIGPIPE, SIG_IGN)
to have the write fail with EPIPE. Killing the client is the same
as if the client called close() from the server’s POV. The client’s
stack sends a FIN and any further reads on the server return 0 (after
any outstanding data in the server’s rcv buffer has been delivered).
I don’t see what reconnecting has to do with it.
-seanb
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
Thanks Sean,
That’s why I’m not treating it as an error, but I don’t see the 'broken
pipe" signal that usually appears with the client-side connection closing.
The other odd part is that after I kill off the client program, the recv
call continues to return with 0 data. Whether it really is the cause or not,
it appears as if the protocol stack is in a tight loop returning a
zero-length message. Surely, a client can’t reconnect and disconnect a
literal million times in less than a minute.
Regards,
David
“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:bksbdk$4h5$> 1@nntp.qnx.com> …
A read of 0 on a socket should be anticipated. It should be
interpreted as EOF (the other end closed the connection).
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
I have a server, using RTP 6.2.0 on a Winsystems PC104 pentium computer.
I’m
using the ntp-tcpip.so stack. My recv call will, occaisionally, be
flooded
by millions of 0 length messages. It seems to handle other messages, but
sluggishly. I only allow a single client to connect and I don’t think it
is
sending the empty data messages because when I shut it down, the string
of 0
length messages continues until I shut down the server process. At that
point, the syslogs of this condition immediately cease.
Is there any related known problem with the 6.2.0 TCP/IP stack? Any
suggestions on what to do to start troubleshooting this problem?
Thanks,
David Kuechenmeister
So after I close the client socket, why does the server socket continue to
return 0?
“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:bkscof$5rn$1@nntp.qnx.com…
SIGPIPE is generated on a write(). Most apps set signal(SIGPIPE, SIG_IGN)
to have the write fail with EPIPE. Killing the client is the same
as if the client called close() from the server’s POV. The client’s
stack sends a FIN and any further reads on the server return 0 (after
any outstanding data in the server’s rcv buffer has been delivered).
I don’t see what reconnecting has to do with it.
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
Thanks Sean,
That’s why I’m not treating it as an error, but I don’t see the 'broken
pipe" signal that usually appears with the client-side connection
closing.
The other odd part is that after I kill off the client program, the recv
call continues to return with 0 data. Whether it really is the cause or
not,
it appears as if the protocol stack is in a tight loop returning a
zero-length message. Surely, a client can’t reconnect and disconnect a
literal million times in less than a minute.
Regards,
David
“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:bksbdk$4h5$> 1@nntp.qnx.com> …
A read of 0 on a socket should be anticipated. It should be
interpreted as EOF (the other end closed the connection).
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
I have a server, using RTP 6.2.0 on a Winsystems PC104 pentium
computer.
I’m
using the ntp-tcpip.so stack. My recv call will, occaisionally, be
flooded
by millions of 0 length messages. It seems to handle other messages,
but
sluggishly. I only allow a single client to connect and I don’t think
it
is
sending the empty data messages because when I shut it down, the
string
of 0
length messages continues until I shut down the server process. At
that
point, the syslogs of this condition immediately cease.
Is there any related known problem with the 6.2.0 TCP/IP stack? Any
suggestions on what to do to start troubleshooting this problem?
Thanks,
David Kuechenmeister
\
We seem to be going in circles here. See my initial post.
The read is probably returning 0 because the other end
closed / was killed. This is normal and expected.
-seanb
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
So after I close the client socket, why does the server socket continue to
return 0?
“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:bkscof$5rn$> 1@nntp.qnx.com> …
SIGPIPE is generated on a write(). Most apps set signal(SIGPIPE, SIG_IGN)
to have the write fail with EPIPE. Killing the client is the same
as if the client called close() from the server’s POV. The client’s
stack sends a FIN and any further reads on the server return 0 (after
any outstanding data in the server’s rcv buffer has been delivered).
I don’t see what reconnecting has to do with it.
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
Thanks Sean,
That’s why I’m not treating it as an error, but I don’t see the 'broken
pipe" signal that usually appears with the client-side connection
closing.
The other odd part is that after I kill off the client program, the recv
call continues to return with 0 data. Whether it really is the cause or
not,
it appears as if the protocol stack is in a tight loop returning a
zero-length message. Surely, a client can’t reconnect and disconnect a
literal million times in less than a minute.
Regards,
David
“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:bksbdk$4h5$> 1@nntp.qnx.com> …
A read of 0 on a socket should be anticipated. It should be
interpreted as EOF (the other end closed the connection).
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
I have a server, using RTP 6.2.0 on a Winsystems PC104 pentium
computer.
I’m
using the ntp-tcpip.so stack. My recv call will, occaisionally, be
flooded
by millions of 0 length messages. It seems to handle other messages,
but
sluggishly. I only allow a single client to connect and I don’t think
it
is
sending the empty data messages because when I shut it down, the
string
of 0
length messages continues until I shut down the server process. At
that
point, the syslogs of this condition immediately cease.
Is there any related known problem with the 6.2.0 TCP/IP stack? Any
suggestions on what to do to start troubleshooting this problem?
Thanks,
David Kuechenmeister
\
David Kuechenmeister wrote:
So after I close the client socket, why does the server socket continue to
return 0?
The read will continue to return 0. When you read a 0 your server needs to
reclaim resources (i.e. close the socket, free memory etc.). The mere fact
that one of these steps implies closing the socket, means that further reads
should not occur (doesn’t make sense to read a closed socket).
Rennie
Rennie Allen <rallen@csical.com> wrote:
David Kuechenmeister wrote:
So after I close the client socket, why does the server socket continue to
return 0?
The read will continue to return 0. When you read a 0 your server needs to
reclaim resources (i.e. close the socket, free memory etc.). The mere fact
that one of these steps implies closing the socket, means that further reads
should not occur (doesn’t make sense to read a closed socket).
Correct. close() or at least don’t continue to read. TCP supports a
half close: the server read() could return 0 if the client did a
shutdown(, SHUT_WR). If you were in such a state the server could continue
write(). If the client did a hard close() and the server continued to
write, that’s when you get into the SIGPIPE / EPIPE on write. In either
case though, once the read return 0, there’s no way for either end
to reinstate data flow in that direction on that socket.
-seanb
I appreciate your patience. Now that you have pointed out what the problem
is, a couple times, I looked through Stevens book and found some appropriate
remedies.
Since we’re on the subject of TCP/IP anyway, I’ll ask another question. Is
there any advantage to reading a byte at a time from the socket, as opposed
to reading a message of up to n bytes?
David
“Rennie Allen” <rallen@csical.com> wrote in message
news:3F71D2B0.6090709@csical.com…
David Kuechenmeister wrote:
So after I close the client socket, why does the server socket continue
to
return 0?
The read will continue to return 0. When you read a 0 your server needs
to
reclaim resources (i.e. close the socket, free memory etc.). The mere
fact
that one of these steps implies closing the socket, means that further
reads
should not occur (doesn’t make sense to read a closed socket).
Rennie
\
David Kuechenmeister wrote:
Since we’re on the subject of TCP/IP anyway, I’ll ask another question. Is
there any advantage to reading a byte at a time from the socket, as opposed
to reading a message of up to n bytes?
There is a general dis-advantage to reading a byte at a time, and that is
poor throughput. Whether there is any advantage to reading a byte at a
time, depends on your application. I have written code that reads a byte
at a time (throughput not critical), and it can make the code simpler
(which is an advantage IMO).
Thanks, that’s the same conclusion I came to. In a lot of the Stevens
examples, he was reading the socket bytewise and I thought there might be
something more to it.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3F71E70D.4080208@csical.com…
David Kuechenmeister wrote:
Since we’re on the subject of TCP/IP anyway, I’ll ask another question.
Is
there any advantage to reading a byte at a time from the socket, as
opposed
to reading a message of up to n bytes?
There is a general dis-advantage to reading a byte at a time, and that is
poor throughput. Whether there is any advantage to reading a byte at a
time, depends on your application. I have written code that reads a byte
at a time (throughput not critical), and it can make the code simpler
(which is an advantage IMO).