home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.protocols.tcp-ip      TCP and IP network protocols.      14,669 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 13,913 of 14,669   
   Jorgen Grahn to dmarkh11@gmail.com   
   Re: Linux: stopping TCP i/o in progress    
   09 Nov 12 14:30:39   
   
   From: grahn+nntp@snipabacken.se   
      
   On Fri, 2012-11-09, dmarkh11@gmail.com wrote:   
   > On Thursday, November 8, 2012 6:23:13 PM UTC-5, Jorgen Grahn wrote:   
   >> On Thu, 2012-11-08, Rick Jones wrote:   
   >>   
   >> > Mark Hounschell wrote:   
   >> ...   
   >> >> Performance is not as critical as emulation accuracy.   
   >> >   
   >> > I do not really want to open another can of worms for you, but   
   >> > depending on the nature of that which you are looking to emulate, you   
   >> > should probably also know that strictly speaking, TCP is not a   
   >> > "reliable transport" in that it does not guarantee delivery.   
   >>   
   >> To open a third can of worms: are we sure he means to use TCP?  He   
   >> mentioned it once (as "Ethernet/TCP"), but from the rest of his   
   >> postings he seem to think mostly in terms of Ethernet and a little   
   >> about IP (he touched on the subject of IP fragmentation).   
   >   
      
   > Fortunately, the device on the other end of the cable of this legacy   
   > controller, which I am also emulating, knows exactly how much data is   
   > to be received from the controller and obviously how much data is   
   > being requested by the controller. I have in place already a software   
   > ACK sequence.   
      
   > But, now I feel sort of stupid as far as TCP/IP is concerned, I am   
   > doing this in a server/client mode. The device is the server and the   
   > controller is the client. The server "listens" for the clients   
   > "connection" then after a connection is established, the server waits   
   > for requests from the client and services them after received. That's   
   > all done using send/recv. Here's the stupid part. Am I using TCP or   
   > IP? I assumed TCP.   
      
   TCP rides on top of IPv4 or IPv6, so when you use TCP you implicitly   
   use IP.  But that's like saying you're using a laser when you're   
   playing a CD or DVD -- true but largely irrelevant.  There's IMHO not   
   a lot of IP functionality which shines through TCP, except for the   
   addresses and the routing.  It's quite different from the UDP   
   situation IMHO.   
      
   > And I assumed it was "reliable". The sockets are   
   > opened:   
      
   >   
   > socket(AF_INET, SOCK_STREAM, 0);   
      
   That's TCP over IPv4.   
      
   ...   
   > Then the server is bound and listens until the client connects.   
   > Forgive my ignorance. This is my first Ethernet project not using UDP.   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca