Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.programmer
Subject: Re: Socket flush...
Message-ID: <1991Mar25.113452.6370@athena.mit.edu>
Date: 25 Mar 91 11:34:52 GMT
References: <519@shrike.AUSTIN.LOCKHEED.COM>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 54

In article <519@shrike.AUSTIN.LOCKHEED.COM>, dcj@AUSTIN.LOCKHEED.COM (David Jacobson rimux) writes:
|>   I have a little different situation than above...maybe someone could
|> shed some light on it:
|> 
|>          __________                 ____________
|>         | "sender" | ---SOCKET---> | "receiver" |
|>         |__________|               |____________|
|> 
|>   My sender is writing data to the receiver via a socket.  The
|> sender is told by another process that all the data it is currently
|> writing to to the receiver is BAD.  Questions:
|> 
|>   Can I clear the socket from the senders end?

  No.  The data is in the kernel buffers for the receiver process, and there's
no way your program can get access to it in order to clear it.  The best you
can do is close the socket completely, but even in that case, the receiver
will still get to read the data you've sent before it sees EOF.

|>   Can I read data from a socket I've been writing to and discard it
|>     (bidirectional) ?

  No.

|>   How would you keep the receiver from processing the remaining
|>     BAD data its reading from the socket?

  If the receiver is cooperating with you, and you are writing the code for
both the sender and receiver, then I see two options:

  1) As someone else has already suggested in response to a slightly different
question (or, at least, I seem to recall it being suggested), the sender and
receiver can connect to each other on another socket that is used for nothing
but exceptional indications.  For example, in this case the sender would send
a message to the receiver telling to, "Hey, my data is bad, flush what's
waiting for you from me and let me know when you're finished!"  The receiver
than reads from the data socket until there's nothing left to read, and sends
an ACK back to the sender on the exception socket.

  2) Use out-of-band data on the data socket -- the sender sends the receiver
an out-of-band message when the data has gone bad, and the receiver sends an
out-of-band message back to the sender when it has cleared the bad data and is
ready to accept good data again.

  Alas, I have never had to use out-of-band data, and as far as I can tell,
the documentation on it is horrendously sparse, so I can't tell you how to do
that (although I suspect that glancing through the sources to rlogin/rlogind
and/or telnet/telnetd will give you hints).

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710