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,910 of 14,669    |
|    dmarkh11@gmail.com to Jorgen Grahn    |
|    Re: Linux: stopping TCP i/o in progress     |
|    09 Nov 12 03:25:31    |
      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. And I assumed it was "reliable". The sockets are       opened:               socket(AF_INET, SOCK_STREAM, 0);       setsockopt(H->sockfd, IPPROTO_TCP, TCP_NODELAY, (char *) &tcpnodelay_flag,       sizeof(int))       setsockopt(H->sockfd, SOL_SOCKET, SO_KEEPALIVE, (char *) &keepalive_flag,       sizeof(int))       setsockopt(H->sockfd, SOL_SOCKET, SO_REUSEADDR, (char *) &reuseaddr_flag,       sizeof(int))              Then the server is bound and listens until the client connects. Forgive my       ignorance. This is my first Ethernet project not using UDP.              Mark              --- 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