> Is there something else that would be causing RSTs in
> the Polygraph traffic?
Certain application-level protocol failures will also trigger RSTs.
For example, if one side of the connection calls close() or
shutdown(SHUT_RD), or shutdown(SHUT_RDWR), it is telling the transport
that it is not expecting any more data to be received on the connection.
If it should happen that additional data _is_ received on the
connection, this will trigger a RST as a signal to the other end that
the application botched its handshake.
In general, the most "robust" way for applications to shutdown their
connections is to call shutdown(SHUT_WR) and then hang in recv calls
until a recv return of 0, indicatin that the other side has also done a
shutdown(SHUT_WR). Then the first side can call close() secure in the
knowledge that no more data will be arriving on the connection.
The SHUT_WR tells the transport the application will be sending no more
data. This causes it to emit a FIN segment. That causes a read return
of zero on the other side - now the other side knows it will recieve no
more data because the other side will send more data. It is safe for
him to either call close(), or shutdown. Those will emit a FIN back to
the other side, which can then "safely" call close().
TCP has no end-to-end signal for "have stopped reading," only a "have
stopped writing" (aka the FIN segment).
rick jones
-- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
This archive was generated by hypermail 2b29 : Mon Feb 06 2006 - 12:00:26 MST