From: rick.jones2@hp.com   
      
   dmarkh11@gmail.com wrote:   
   > On Tuesday, November 6, 2012 4:18:37 PM UTC-5, Rick Jones wrote:   
   > > What exactly do you mean by an I/O in progress?   
   > >   
      
   > For a single send(), I/O in progress would be the time between when   
   > the Ethernet controller starts putting your data on the wire and   
   > when it is finished putting your data on the wire. I want, if   
   > possible, to be able to interrupt that process, within the   
   > controller, mid flight like I can do with the legacy i/o controller   
   > I am trying to emulate.   
      
   From the application layer, using sockets, you have no control over   
   what is happening down at Ethernet.  You have no control over what is   
   happening at IP and extremely limited control over what is happening   
   in TCP.  A send() call is not really "synchronous."   
      
   If the socket is marked non-blocking, the send() call completes once   
   the last byte of the send has been copied into the socket buffer.  The   
   call does not wait for the data to be sent by Ethernet, or IP, or TCP.   
      
   Once the send() call completes, from that point on, there is no   
   control (that I can think of) short of closing the socket to keep TCP   
   from trying to keep sending it.   
      
   If the socket buffer has enough space to hold the data, then the time   
   in the send() call will be very short - just the copy time.  It will   
   not include any delays getting the data across the network.   
      
   Only if the socket buffer is full or fills before the last byte of the   
   send() call is copied will the call sit for some length of time.  I   
   suppose in that case one *might* be able to send a signal to the   
   process/thread making the send() call and the send() call may then   
   return with a short write,(I'm guessing but have never tried it) but   
   it will not preclude TCP from continuing to try to transmit the data   
   it has been given.  Again, even then the send() call will complete   
   likely before the last bytes of data have even gotten to the transmit   
   queue of the Ethernet interface.   
      
   > > Generally speaking.  If you want TCP to stop sending, you stop giving   
   > > it data.  You cannot prevent it from trying to transmit data you have   
   > > given it.  If you want TCP to stop receiving, you stop pulling data   
   > > out of the connection.  That does not "immediately" stop the sending   
   > > side, but it will stop once it either has no more data to send, or the   
   > > TCP receive window fills, whichever comes first.   
   > >   
   > > Even if there were an "xoff" ability at a TCP receiver, there will   
   > > still be the delay as that flowed across the network to the sender.   
   > > It could not be "immediate."   
      
   > So even the aio interface, aio_cancel(), can't actually halt i/o in   
   > progress, as I defined it above?   
      
   Well, it may halt that aio_call, but it will be rather a race as to   
   how long that aio call sits there - again if there is space in the   
   socket buffer it will remain outstanding only as long as it takes to   
   copy the data to the socket buffer.  And any data already given to TCP   
   (per the above) will still be sent.   
      
   I am not familiar with a copy-avoiding semantic for aio over sockets   
   in Linux (though in theory there could be one) - epecially not one   
   that would only complete once all the bytes were delivered by TCP (and   
   ACKnowledged by the receiving TCP).   
      
   In the inbound direction, if there is no data to give an aio_read()   
   sure it will sit there for a while and probably be cancellable (and   
   perhaps a recv() call), but again, that will not affect TCP's   
   willingness to continue to receive data from the remote.   
      
   There is shutdown(SHUT_WR) but all that tells TCP is you will be   
   providing it with no more data.  It does not preclude it from   
   continuing to attempt to send the data it has already been given.   
   There is shutdown(SHUT_RD) that tells TCP you expect to receive no   
   more data.  If data then arrives at TCP from the remote, TCP will   
   abort the connection.  They cannot be used as an XON/XOFF kind of   
   thing though.   
      
   rick jones   
   --   
   Don't anthropomorphize computers.  They hate that.  - Anonymous   
   these opinions are mine, all mine; HP might not want them anyway... :)   
   feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)