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 |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca