From owner-tcp-impl@lerc.nasa.gov Fri Feb 2 15:14:42 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25885 for ; Fri, 2 Feb 2001 15:14:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA23227 for tcp-impl-outgoing; Fri, 2 Feb 2001 12:49:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA23202 for ; Fri, 2 Feb 2001 12:49:11 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA07191; Fri, 2 Feb 2001 12:49:09 -0500 Received: from operation.dublin.iona.ie(212.120.147.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007109; Fri, 2 Feb 01 12:49:00 -0500 Received: from lukeskywalker ([10.2.3.23]) by dublin.iona.ie (8.8.8/iona-1.02) with SMTP id RAA06580 for ; Fri, 2 Feb 2001 17:49:38 GMT From: "ravi reddy" To: Subject: time of queued connections if not reaped... Date: Fri, 2 Feb 2001 17:44:14 -0000 Message-ID: <00c201c08d3f$c1d6cdb0$1703020a@lukeskywalker.dublin.iona.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: <200011101531.HAA29719@boreas.isi.edu> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, In the product that I'm currently working in, we have clients and servers. The server has a leader-follower pattern of threads which monitor the connections or data that come as the result of fds that fire from the select set. (the fd could be listener fd for which a new client connection comes when it fires or a old fd with some data). Now the question is?. When the server runs out of FDs, I remove the listener FD from the select set as I don't want to talk to any client. Coming to the TCP/IP internals, I believe any new client connections will queue up in the queue with backlog mentioned by listen() system call until reaped by accept() call. If queue is full, any new clients will timeout as they cannot contact the server. I believe the time in this case is 75 seconds which is the establishment timer. Now what I want to know is if the server never issues an accept() call to take these connections off the queue (this will happen because we pulled out the listener FD from the select set and so it won't fire), FOR HOW LONG will these connections stay in the queue. I presume any client that sends data to the connection which is in a ESTABLISHED state and queued at server, it starts a retransmission timer and no response after 5 or 9 minutes (recommended default of 12 retrasmissions) will elicit a RST from the client side to the server side. As a result of this, the server TCP/IP will remove the established connection from the queue. So is the time related to retransmission timer?. Any help greatly appreciated. Have a nice day, Ravi. From owner-tcp-impl@lerc.nasa.gov Fri Feb 2 16:43:27 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00450 for ; Fri, 2 Feb 2001 16:43:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA13885 for tcp-impl-outgoing; Fri, 2 Feb 2001 14:38:38 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA13845 for ; Fri, 2 Feb 2001 14:38:31 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA19978; Fri, 2 Feb 2001 14:38:30 -0500 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019912; Fri, 2 Feb 01 14:37:54 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 01B6396B; Fri, 2 Feb 2001 11:37:53 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id LAA25913; Fri, 2 Feb 2001 11:37:53 -0800 (PST) Message-ID: <3A7B0C91.C4B3937B@cup.hp.com> Date: Fri, 02 Feb 2001 11:37:53 -0800 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: ravi reddy Cc: tcp-impl@grc.nasa.gov Subject: Re: time of queued connections if not reaped... References: <00c201c08d3f$c1d6cdb0$1703020a@lukeskywalker.dublin.iona.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > When the server runs out of FDs, I remove the listener FD from the select > set as I don't want to talk to any client. Coming to the TCP/IP internals, I > believe any new client connections will queue up in the queue with backlog > mentioned by listen() system call until reaped by accept() call. If queue is > full, any new clients will timeout as they cannot contact the server. I > believe the time in this case is 75 seconds which is the establishment > timer. Now what I want to know is if the server never issues an accept() > call to take these connections off the queue (this will happen because we > pulled out the listener FD from the select set and so it won't fire), FOR > HOW LONG will these connections stay in the queue. I presume any client that > sends data to the connection which is in a ESTABLISHED state and queued at > server, it starts a retransmission timer and no response after 5 or 9 > minutes (recommended default of 12 retrasmissions) will elicit a RST from > the client side to the server side. As a result of this, the server TCP/IP > will remove the established connection from the queue. > > So is the time related to retransmission timer?. My guess would be probably not. The client will be able to send data - the connection is ESTABLISHED, and that data will likely be accepted and ACKed. My guess would be that those connections in the listen queue will stay there for quite a long time. Basically until the client gets fed-up with a lack of response and closes. Or, you explicitly accept and close them yourself. I have no guess as to what would happen if you went and did a listen(s,0) listen(s,1)... If you really want those connections to go away without more direct intervention, you might want to use an interface that inserts the application between the receipt of the SYN and the sending of the SYN|ACK. I _think_ XTI is or can be such an interface. In that case, you would simply stop taking the request notificatoins and the clients would timeout on their connects. rick jones -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Fri Feb 2 18:34:28 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05065 for ; Fri, 2 Feb 2001 18:34:28 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA03669 for tcp-impl-outgoing; Fri, 2 Feb 2001 16:28:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA03630 for ; Fri, 2 Feb 2001 16:28:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA03314; Fri, 2 Feb 2001 16:28:21 -0500 Received: from mentat.com(192.88.122.129) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003260; Fri, 2 Feb 01 16:27:33 -0500 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA00225; Fri, 2 Feb 2001 13:20:49 -0800 (PST) Received: from rock.mentat.com (rock [192.88.122.163]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with SMTP id NAA18753; Fri, 2 Feb 2001 13:20:48 -0800 (PST) Received: by rock.mentat.com (SMI-8.6/SMI-SVR4) id NAA06136; Fri, 2 Feb 2001 13:20:24 -0800 Date: Fri, 2 Feb 2001 13:20:24 -0800 From: jt@mentat.com (Jerry Toporek) Message-Id: <200102022120.NAA06136@rock.mentat.com> To: Ravi.Reddy@iona.com, raj@cup.hp.com Subject: Re: time of queued connections if not reaped... Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > If you really want those connections to go away without more direct > intervention, you might want to use an interface that inserts the > application between the receipt of the SYN and the sending of the > SYN|ACK. I _think_ XTI is or can be such an interface. In that case, you > would simply stop taking the request notificatoins and the clients would > timeout on their connects. > Rick: I don't know of any TCP implementation that withholds the SYN-ACK until the application accepts the connection. I do know that if you experiment with such a strategy, you will find that BSD-based implementations of FTP will be unable to successfully establish a data connection. It's been a long time since I stumbled into this, so the details are fuzzy, but basically you get into a deadlock where the client doesn't try to accept the data connection until it receives a message on the control connection, but the server doesn't send that message on the control connection until the data connection is established. This works only if the SYN-ACK for the data connection is sent without waiting for the accept. It may be the case that XTI (or would that really be TPI?) intended for the application to control whether or not an inbound connection ever gets to established state. This sounds like a pretty good idea, but having FTP break is not acceptable. FTP implementations that work this way could, of course, be "fixed", but that isn't going to happen. jt From owner-tcp-impl@lerc.nasa.gov Fri Feb 2 19:58:50 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07842 for ; Fri, 2 Feb 2001 19:58:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA15487 for tcp-impl-outgoing; Fri, 2 Feb 2001 18:02:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA15462 for ; Fri, 2 Feb 2001 18:02:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA12645; Fri, 2 Feb 2001 18:02:55 -0500 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012616; Fri, 2 Feb 01 18:02:18 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 84FEFCCB; Fri, 2 Feb 2001 15:02:17 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id PAA04511; Fri, 2 Feb 2001 15:02:17 -0800 (PST) Message-ID: <3A7B3C79.E791DE3@cup.hp.com> Date: Fri, 02 Feb 2001 15:02:17 -0800 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Cc: Ravi.Reddy@iona.com Subject: Re: time of queued connections if not reaped... References: <200102022120.NAA06136@rock.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > It may be the case that XTI (or would that really be TPI?) intended for the > application to control whether or not an inbound connection ever gets to Certainly, that is what I infered from the manpages for t_listen and t_accept :) rick -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Sat Feb 3 14:09:34 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08780 for ; Sat, 3 Feb 2001 14:09:33 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24888 for tcp-impl-outgoing; Sat, 3 Feb 2001 12:07:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA24782 for ; Sat, 3 Feb 2001 12:07:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA12671; Sat, 3 Feb 2001 12:07:27 -0500 Received: from operation.dublin.iona.ie(212.120.147.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012622; Sat, 3 Feb 01 12:06:31 -0500 Received: from lukeskywalker ([10.2.3.23]) by dublin.iona.ie (8.8.8/iona-1.02) with SMTP id PAA15078; Sat, 3 Feb 2001 15:40:44 GMT From: "ravi reddy" To: , Subject: RE: time of queued connections if not reaped... Date: Sat, 3 Feb 2001 15:35:19 -0000 Message-ID: <00d501c08df6$e9f78d40$1703020a@lukeskywalker.dublin.iona.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: <3A7B0C91.C4B3937B@cup.hp.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > My guess would be probably not. The client will be able to send data - > the connection is ESTABLISHED, and that data will likely be accepted and > ACKed. My guess would be that those connections in the listen queue will > stay there for quite a long time. Assuming client sends data for the ESTABLISHED connection which is queued in the socket receive buffer on the server side and the data fills the buffer, then I presume the client's TCP will never get any ACKs for the additional data sent and will eventually timeout which is the retransmission timeout. > Basically until the client gets fed-up with a lack of response and closes. Any idea of the situations when it would get fed up. > Or, you explicitly accept and close them yourself. In my case server won't accept() or close() the connections as it is out of FDs and it will do so only if the FD count goes down. The problem here is that any data sent by client using the ESTABLISHED connection will be put into socket receive buffer and will probably be ACKed. But if I issue an accept() call, it will reap a connection from the listen queue and will overlay the connection onto a FD whose creation will fail as the server is out of FDs. > I have no guess as to what would happen if you went and did a > listen(s,0) listen(s,1)... You mean to say that I issue an listen(s,0) or listen(s,1) when the server runs out of FDs. We call listen with a backlog of 5 and then wait for any FDs to fire from the select set. I haven't investigated this scenario. > If you really want those connections to go away without more direct > intervention, you might want to use an interface that inserts the > application between the receipt of the SYN and the sending of the > SYN|ACK. I _think_ XTI is or can be such an interface. In that case, you > would simply stop taking the request notificatoins and the clients would > timeout on their connects. This is out of question right now with the tight schedules. Could you please clarify one more QUESTION?. Any clients SYNs will be put into incomplete connection queue waiting for the three-way handshake to complete. But since the complete connection queue is full, how would TCP handle this scenario. Though it can complete the three-way handshake, it can't move this incomplete connection to the complete connection queue as the queue is full. I guess the server's TCP will not complete the three-way handshake until the complete connection queue has space and those SYNs will be ignored and the clients will timeout after 75 seconds which is the establishment timer. If both the queues are full, the client's SYN will be ignored and will these clients stop trying after the expiry of establishment timer of 75 seconds?. Thank you very much for the response. regards, Ravi. From owner-tcp-impl@lerc.nasa.gov Sat Feb 3 15:15:07 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10533 for ; Sat, 3 Feb 2001 15:15:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA00751 for tcp-impl-outgoing; Sat, 3 Feb 2001 13:16:50 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA00727 for ; Sat, 3 Feb 2001 13:16:47 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA19472; Sat, 3 Feb 2001 13:16:46 -0500 Received: from mail-blue.research.att.com(135.207.30.102) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019459; Sat, 3 Feb 01 13:16:12 -0500 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 424BE4CE15; Sat, 3 Feb 2001 13:16:11 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA19587; Sat, 3 Feb 2001 13:16:05 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA20144; Sat, 3 Feb 2001 10:16:05 -0800 (PST) Message-Id: <200102031816.KAA20144@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: raj@cup.hp.com Subject: Re: time of queued connections if not reaped... Cc: ravi.reddy@iona.com, tcp-impl@grc.nasa.gov References: <00c201c08d3f$c1d6cdb0$1703020a@lukeskywalker.dublin.iona.ie> <3A7B0C91.C4B3937B@cup.hp.com> Date: Sat, 3 Feb 2001 10:16:04 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I remember seeing someone talk about an experiment with the BSD API where it didn't send the SYN/ACK until the first IO operation was posted to the socket. This meant that a knowledgable program could accept() and then close the new socket if it didn't like it, and normal programs would (should?) be relatively unaffected. I thought it sounded like a cool idea when I read about it but I never tried the experiment myself. Bill From owner-tcp-impl@lerc.nasa.gov Sat Feb 3 21:24:37 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05795 for ; Sat, 3 Feb 2001 21:24:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA15772 for tcp-impl-outgoing; Sat, 3 Feb 2001 19:40:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA15764 for ; Sat, 3 Feb 2001 19:40:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA09081; Sat, 3 Feb 2001 19:40:06 -0500 Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009027; Sat, 3 Feb 01 19:39:10 -0500 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id TAA08515; Sat, 3 Feb 2001 19:39:06 -0500 (EST) Date: Sat, 3 Feb 2001 19:39:06 -0500 (EST) From: der Mouse Message-Id: <200102040039.TAA08515@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: time of queued connections if not reaped... Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit >> [...] an interface that inserts the application between the receipt >> of the SYN and the sending of the SYN|ACK. I used something similar, way back when, albeit with DECnet rather than TCP. As I recall the interface, and mapping it into TCP terms, the way it worked was that you set some socket option on the listening socket (with setsockopt()) and then accept() returned a socket that was still in SYN_RCVD, and you had to take explicit action to send the SYN-ACK (which of course you had to do before you could do much more than getpeername() on the new socket). Of course, an application using this interface will be comparatively easy to DoS with a synflood, but that's unavoidable. > I don't know of any TCP implementation that withholds the SYN-ACK > until the application accepts the connection. I do know that if you > experiment with such a strategy, you will find that BSD-based > implementations of FTP will be unable to successfully establish a > data connection. It's been a long time since I stumbled into this, > so the details are fuzzy, but basically you get into a deadlock where > the client doesn't try to accept the data connection until it > receives a message on the control connection, but the server doesn't > send that message on the control connection until the data connection > is established. All this means is that the listening side (client for PORT style, server for PASV style) mustn't turn on the relevant option on its data connection socket. Since most applications don't want this option, the default should be off, which means that FTP code that's unaware of the option will behave correctly. If an FTP client or server is modified to turn the option on, of course, it will have to also be modified to avoid deadlocking as a result. I don't consider this a problem. If you try to change the system-wide default, well, you've introduced a fundamental major change in the semantics of the interface, so it's no surprise if unchanged code breaks. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Sat Feb 3 22:20:38 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09648 for ; Sat, 3 Feb 2001 22:20:37 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA17809 for tcp-impl-outgoing; Sat, 3 Feb 2001 20:38:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA17789 for ; Sat, 3 Feb 2001 20:38:09 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA11498; Sat, 3 Feb 2001 20:38:08 -0500 Received: from mentat.com(192.88.122.129) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011489; Sat, 3 Feb 01 20:38:03 -0500 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA04963; Sat, 3 Feb 2001 17:39:21 -0800 (PST) Received: from rock.mentat.com (rock [192.88.122.163]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with SMTP id RAA15707; Sat, 3 Feb 2001 17:39:21 -0800 (PST) Received: by rock.mentat.com (SMI-8.6/SMI-SVR4) id RAA06880; Sat, 3 Feb 2001 17:38:56 -0800 Date: Sat, 3 Feb 2001 17:38:56 -0800 From: jt@mentat.com (Jerry Toporek) Message-Id: <200102040138.RAA06880@rock.mentat.com> To: tcp-impl@grc.nasa.gov, mouse@Rodents.Montreal.QC.CA Subject: Re: time of queued connections if not reaped... X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > All this means is that the listening side (client for PORT style, > server for PASV style) mustn't turn on the relevant option on its data > connection socket. Since most applications don't want this option, the > default should be off, which means that FTP code that's unaware of the > option will behave correctly. If an FTP client or server is modified > to turn the option on, of course, it will have to also be modified to > avoid deadlocking as a result. I don't consider this a problem. > Sure... As an option on the listener it should work fine, and isn't very hard to implement. jt From owner-tcp-impl@lerc.nasa.gov Sun Feb 4 07:59:35 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08244 for ; Sun, 4 Feb 2001 07:59:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA09625 for tcp-impl-outgoing; Sun, 4 Feb 2001 06:06:22 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA09614; Sun, 4 Feb 2001 06:06:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA05633; Sun, 4 Feb 2001 06:06:17 -0500 Received: from chopin.cti.depaul.edu(140.192.32.72) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005613; Sun, 4 Feb 01 06:05:50 -0500 Received: from ehab2000 ([140.192.162.13]) by CHOPIN.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.1600); Sun, 4 Feb 2001 05:05:40 -0600 Message-ID: <01e701c08e9a$80b22440$0da2c08c@cti.depaul.edu> From: "Ehab Al-Shaer" To: Subject: MMNS 2001 Call For Papers -- Date: Sun, 4 Feb 2001 05:06:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 04 Feb 2001 11:05:40.0918 (UTC) FILETIME=[694DAD60:01C08E9A] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001 Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 Conference: October 29 to Nov 1, 2001 The IFIP/IEEE MMNS is the premier IEEE/IFIP conferences focusing on management of multimedia networks and services. The conference is known for its high-quality papers from various research communities. Selected papers will also be considered for publication as a special issue of the Journal of High Speed Networking and Journal of Networks and Information Systems. MMNS 2001 will provide Travel and Conference Scholarships for students. Topics of interest include, but are not limited to, the following: Distributed multimedia service management Integration of network control and management Network management models and architectures Distributed event correlation Monitoring QoS management Multimedia traffic management Resource, performance and fault management for broadband networks Configuration management of edge and core services for enabling multimedia traffic management Multi-point and multicast services management Resource management in wireless multimedia Wireless and mobile network management Mobility management Management of ad-hoc networks Multimedia content protection Deployment of multimedia services Active network management Network programmability for multimedia services Middleware support for management Multimedia session management Packet scheduling and dropping techniques Multimedia service Engineering Billing and security for broadband networks Policy-based management for multimedia service PAPER SUBMISSION See . From owner-tcp-impl@lerc.nasa.gov Mon Feb 5 16:12:18 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17686 for ; Mon, 5 Feb 2001 16:12:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA29033 for tcp-impl-outgoing; Mon, 5 Feb 2001 13:54:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA28984 for ; Mon, 5 Feb 2001 13:54:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA13904; Mon, 5 Feb 2001 13:54:03 -0500 Received: from operation.dublin.iona.ie(212.120.147.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013839; Mon, 5 Feb 01 13:53:49 -0500 Received: from lukeskywalker ([10.2.3.23]) by dublin.iona.ie (8.8.8/iona-1.02) with SMTP id SAA00435 for ; Mon, 5 Feb 2001 18:54:30 GMT From: "ravi reddy" To: Subject: Which implementation is better... Date: Mon, 5 Feb 2001 18:49:01 -0000 Message-ID: <011301c08fa4$4e4fb930$1703020a@lukeskywalker.dublin.iona.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: <3A7B3C79.E791DE3@cup.hp.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, We have clients and servers in our product. When the server runs out of FDs, we usually remove the listener FD from the select set and register it back when any FD is freed. Are there any drawbacks with this solution?. Currently we have connection timeouts and so the clients will timeout fast enough without waiting for server to accept the connections or until the keepalive probes kickin. But infinite connection timeouts are not also ruled out in the implemenation. What are the drawbacks of closing the listener socket and binding it again to the same port?. The only drawback I can think of right now is that the port could be reused by the OS and the server which has closed its listener socket will not be able to bind to it. Any help greatly appreciated. regards, Ravi. From owner-tcp-impl@lerc.nasa.gov Mon Feb 5 16:16:53 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17767 for ; Mon, 5 Feb 2001 16:16:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA02869 for tcp-impl-outgoing; Mon, 5 Feb 2001 14:12:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA02825 for ; Mon, 5 Feb 2001 14:12:15 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA16391; Mon, 5 Feb 2001 14:12:12 -0500 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016347; Mon, 5 Feb 01 14:11:15 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 613A3449; Mon, 5 Feb 2001 11:11:14 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id LAA01358; Mon, 5 Feb 2001 11:11:14 -0800 (PST) Message-ID: <3A7EFAD1.7B2741D5@cup.hp.com> Date: Mon, 05 Feb 2001 11:11:13 -0800 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: ravi reddy Cc: tcp-impl@grc.nasa.gov Subject: Re: time of queued connections if not reaped... References: <00d501c08df6$e9f78d40$1703020a@lukeskywalker.dublin.iona.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit ravi reddy wrote: > > > My guess would be probably not. The client will be able to send data - > > the connection is ESTABLISHED, and that data will likely be accepted and > > ACKed. My guess would be that those connections in the listen queue will > > stay there for quite a long time. > > Assuming client sends data for the ESTABLISHED connection which is queued > in the socket receive buffer on the server side and the data fills the > buffer, then I presume the client's TCP will never get any ACKs for the > additional data sent and will eventually timeout which is the retransmission > timeout. While there are some stacks that "lie" about their window and amount of data they can store, 99 times out of ten, if the receive socket buffer is full, the sender has a zero window, and so unless it is broken, will not be sending and data that will be dropped without an ACK. > > Basically until the client gets fed-up with a lack of response and closes. > > Any idea of the situations when it would get fed up. Client-level timeouts, people sitting at keyboards hitting ^C, or "STOP" buttons. That sort of thing. > > Or, you explicitly accept and close them yourself. > > In my case server won't accept() or close() the connections as it is out > of FDs and it will do so only if the FD count goes down. The problem here is > that any data sent by client using the ESTABLISHED connection will be put > into socket receive buffer and will probably be ACKed. But if I issue an > accept() call, it will reap a connection from the listen queue and will > overlay the connection onto a FD whose creation will fail as the server is > out of FDs. Just what is your FD limit? On the "enterprise ready" :) platforms, or at least two with which I'm slghtly familiar, the per-process FD limit is either 32768 or 60000 - the kernel being configured apropriately. > > If you really want those connections to go away without more direct > > intervention, you might want to use an interface that inserts the > > application between the receipt of the SYN and the sending of the > > SYN|ACK. I _think_ XTI is or can be such an interface. In that case, you > > would simply stop taking the request notificatoins and the clients would > > timeout on their connects. > > This is out of question right now with the tight schedules. As others have pointed-out, which the XTI interface routines and their descriptions imply what I thought would happen, the actual implementations may not behave quite that way. rick -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Tue Feb 6 13:28:06 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27202 for ; Tue, 6 Feb 2001 13:28:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA09901 for tcp-impl-outgoing; Tue, 6 Feb 2001 10:49:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA09851 for ; Tue, 6 Feb 2001 10:49:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA21613; Tue, 6 Feb 2001 10:49:21 -0500 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021578; Tue, 6 Feb 01 10:49:09 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id KAA81026; Tue, 6 Feb 2001 10:48:34 -0500 (EST) (envelope-from craig@aland.bbn.com) Message-Id: <200102061548.KAA81026@aland.bbn.com> To: Bill Fenner cc: tcp-impl@grc.nasa.gov Subject: Re: time of queued connections if not reaped... In-reply-to: Your message of "Sat, 03 Feb 2001 10:16:04 PST." <200102031816.KAA20144@windsor.research.att.com> Date: Tue, 06 Feb 2001 10:48:33 -0500 From: Craig Partridge Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk In message <200102031816.KAA20144@windsor.research.att.com>, Bill Fenner writes : > >I remember seeing someone talk about an experiment with the BSD API >where it didn't send the SYN/ACK until the first IO operation was >posted to the socket. This meant that a knowledgable program could >accept() and then close the new socket if it didn't like it, and >normal programs would (should?) be relatively unaffected. As I recall this wasn't easy. The problem is that some sockets don't do IO -- they do an accept and then hang a select() -- so basically you have to go through and change a lot of code to make this work. Craig From owner-tcp-impl@lerc.nasa.gov Wed Feb 7 14:54:18 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07646 for ; Wed, 7 Feb 2001 14:54:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24846 for tcp-impl-outgoing; Wed, 7 Feb 2001 12:23:10 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA24813 for ; Wed, 7 Feb 2001 12:23:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA16132; Wed, 7 Feb 2001 12:23:06 -0500 Received: from patan.sun.com(192.18.98.43) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016091; Wed, 7 Feb 01 12:22:32 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09702; Wed, 7 Feb 2001 09:22:25 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23189; Wed, 7 Feb 2001 09:22:24 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f17HMJR675405; Wed, 7 Feb 2001 09:22:20 -0800 (PST) Date: Wed, 7 Feb 2001 18:22:00 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: time of queued connections if not reaped... To: Craig Partridge Cc: Bill Fenner , tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" <200102061548.KAA81026@aland.bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > In message <200102031816.KAA20144@windsor.research.att.com>, Bill Fenner > writes : > > > > >I remember seeing someone talk about an experiment with the BSD API > >where it didn't send the SYN/ACK until the first IO operation was > >posted to the socket. This meant that a knowledgable program could > >accept() and then close the new socket if it didn't like it, and > >normal programs would (should?) be relatively unaffected. The TCP implementation done by Mentat that went into Solaris 2.0 originally had a knob where the SYN/ACK could be deferred until the application called accept(). Even this caused problems for ftp/ftpd if I recall correctly - the establishment of the data connection has some dependencies on the connect() returning before the other end is told to call accept(). Erik From owner-tcp-impl@lerc.nasa.gov Wed Feb 14 16:20:45 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17046 for ; Wed, 14 Feb 2001 16:20:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA01224 for tcp-impl-outgoing; Wed, 14 Feb 2001 13:37:51 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA01216 for ; Wed, 14 Feb 2001 13:37:50 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA29785; Wed, 14 Feb 2001 13:37:49 -0500 Received: from unknown(212.155.143.61) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029043; Wed, 14 Feb 01 13:35:53 -0500 Received: by smtp.nettoll.com; Wed, 14 Feb 2001 19:31:32 +0100 (MET) Message-Id: <4.3.0.20010214191202.043c15a0@pop.free.fr> X-Sender: mchilali@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 14 Feb 2001 19:32:45 +0100 To: "ravi reddy" , From: Mahmoud Chilali Subject: Re: Which implementation is better... In-Reply-To: <011301c08fa4$4e4fb930$1703020a@lukeskywalker.dublin.iona.i e> References: <3A7B3C79.E791DE3@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk When you close the fd, the socket is not immediately freed at the TCP level. so the port will be "already in use" even if no application is using it. This may be either annoying or not a problem depending on your requirements. I personally prefer setting a max-connections threeshold (this should be less than the number of fds per process), and if the threshold is reached, accept the connection and close it immediately. The time this takes is short enough compared to what you need as timeouts. regards Mahmoud At 18:49 05/02/01 +0000, ravi reddy wrote: > Hi all, > > We have clients and servers in our product. When the server runs out of >FDs, we usually remove the listener FD from the select set and register it >back when any FD is freed. Are there any drawbacks with this solution?. >Currently we have connection timeouts and so the clients will timeout fast >enough without waiting for server to accept the connections or until the >keepalive probes kickin. But infinite connection timeouts are not also ruled >out in the implemenation. > > What are the drawbacks of closing the listener socket and binding it again >to the same port?. The only drawback I can think of right now is that the >port could be reused by the OS and the server which has closed its listener >socket will not be able to bind to it. > > Any help greatly appreciated. > > regards, > Ravi. From owner-tcp-impl@lerc.nasa.gov Wed Feb 14 16:20:52 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17057 for ; Wed, 14 Feb 2001 16:20:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA05527 for tcp-impl-outgoing; Wed, 14 Feb 2001 13:58:42 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA05494 for ; Wed, 14 Feb 2001 13:58:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA02760; Wed, 14 Feb 2001 13:58:37 -0500 Received: from operation.dublin.iona.ie(212.120.147.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002714; Wed, 14 Feb 01 13:58:24 -0500 Received: from lukeskywalker ([10.2.3.23]) by dublin.iona.ie (8.8.8/iona-1.02) with SMTP id SAA22429; Wed, 14 Feb 2001 18:59:04 GMT From: "ravi reddy" To: "Mahmoud Chilali" , Subject: RE: Which implementation is better... Date: Wed, 14 Feb 2001 18:53:21 -0000 Message-ID: <02c001c096b7$6721e4f0$1703020a@lukeskywalker.dublin.iona.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: <4.3.0.20010214191202.043c15a0@pop.free.fr> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit We do have a threshold. When the threshold is reached, we remove the listener FD from the select FD set and issue a listen() call of 0. When the FD count goes down, we put back the listener FD and reset the listen queue length. The only issue with this is that clients will wait for 75 seconds before timing out (listen() call of 0 is ignored by BSD implementations which allow one connection to go through to the complete connection queue and this client will indefinitely wait). Other than using client-level timeouts, we have no way to make these clients timeout before 75 seconds. If there is a way, please let me know. > I personally prefer setting a max-connections threeshold (this should be > less than the number of fds per process), and if the threshold is reached, > accept the connection and close it immediately. The time this takes is > short enough compared to what you need as timeouts. What this does is it makes the listener thread unnecessarily spin (by accepting and closing) without doing any meaningful work. Thanks, ravi. > At 18:49 05/02/01 +0000, ravi reddy wrote: > > > Hi all, > > > > We have clients and servers in our product. When the server > runs out of > >FDs, we usually remove the listener FD from the select set and > register it > >back when any FD is freed. Are there any drawbacks with this solution?. > >Currently we have connection timeouts and so the clients will > timeout fast > >enough without waiting for server to accept the connections or until the > >keepalive probes kickin. But infinite connection timeouts are > not also ruled > >out in the implemenation. > > > > What are the drawbacks of closing the listener socket and > binding it again > >to the same port?. The only drawback I can think of right now is that the > >port could be reused by the OS and the server which has closed > its listener > >socket will not be able to bind to it. > > > > Any help greatly appreciated. > > > > regards, > > Ravi. > From owner-tcp-impl@lerc.nasa.gov Wed Feb 14 17:26:00 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18050 for ; Wed, 14 Feb 2001 17:25:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA15800 for tcp-impl-outgoing; Wed, 14 Feb 2001 14:48:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA15778 for ; Wed, 14 Feb 2001 14:48:57 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA09922; Wed, 14 Feb 2001 14:48:57 -0500 Received: from router-100m.swansea.linux.org.uk(194.168.151.17) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009754; Wed, 14 Feb 01 14:48:44 -0500 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14T7uL-0005p3-00; Wed, 14 Feb 2001 19:48:10 +0000 Subject: Re: Which implementation is better... To: Ravi.Reddy@iona.com (ravi reddy) Date: Wed, 14 Feb 2001 19:48:04 +0000 (GMT) Cc: chilali@chilali.net (Mahmoud Chilali), tcp-impl@grc.nasa.gov In-Reply-To: <02c001c096b7$6721e4f0$1703020a@lukeskywalker.dublin.iona.ie> from "ravi reddy" at Feb 14, 2001 06:53:21 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > We do have a threshold. When the threshold is reached, we remove the > listener FD from the select FD set and issue a listen() call of 0. When the > FD count goes down, we put back the listener FD and reset the listen queue > length. The only issue with this is that clients will wait for 75 seconds > before timing out (listen() call of 0 is ignored by BSD implementations > which allow one connection to go through to the complete connection queue > and this client will indefinitely wait). Other than using client-level > timeouts, we have no way to make these clients timeout before 75 seconds. If > there is a way, please let me know. Listen counts are also ignored by hosts using syncookies. From owner-tcp-impl@lerc.nasa.gov Thu Feb 15 16:47:48 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01050 for ; Thu, 15 Feb 2001 16:47:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA14538 for tcp-impl-outgoing; Thu, 15 Feb 2001 14:03:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA14530 for ; Thu, 15 Feb 2001 14:03:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA12184; Thu, 15 Feb 2001 14:03:05 -0500 Received: from unknown(212.155.143.61) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011334; Thu, 15 Feb 01 14:00:43 -0500 Received: by smtp.nettoll.com; Thu, 15 Feb 2001 19:56:35 +0100 (MET) Message-Id: <4.3.0.20010215194812.03f20c40@pop.free.fr> X-Sender: mchilali@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 15 Feb 2001 19:57:47 +0100 To: "ravi reddy" , From: Mahmoud Chilali Subject: RE: Which implementation is better... In-Reply-To: <02c001c096b7$6721e4f0$1703020a@lukeskywalker.dublin.iona.i e> References: <4.3.0.20010214191202.043c15a0@pop.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk At 18:53 14/02/01 +0000, ravi reddy wrote: > We do have a threshold. When the threshold is reached, we remove the >listener FD from the select FD set and issue a listen() call of 0. note that the backlog argument to listen is interepreted in a system dependent manner. >When the >FD count goes down, we put back the listener FD and reset the listen queue >length. The only issue with this is that clients will wait for 75 seconds >before timing out (listen() call of 0 is ignored by BSD implementations >which allow one connection to go through to the complete connection queue >and this client will indefinitely wait). Other than using client-level >timeouts, we have no way to make these clients timeout before 75 seconds. If >there is a way, please let me know. the close after accept is probably faster (I don't have the state diag at hands). > What this does is it makes the listener thread unnecessarily spin (by >accepting and closing) >without doing any meaningful work. probably, but replacing a "accept+close" with a "listen+listen" or with a "close+socket+bind+listen" doesn't add any meaningful stuff here. (Also, note that a program generally spends its time doing things that are not meaningful:) The problem with your approach is that you add design constraints just to cope with a situation that should be exceptional. The accept/close approach is trivial and won't "happen" under normal circumstances (by normal circumstances, I mean that you configure your system and software to have the correct threshold, and if the clients are yours, configure them to be "friendly"....) regards, Mahmoud From owner-tcp-impl@lerc.nasa.gov Sat Feb 17 06:08:44 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02731 for ; Sat, 17 Feb 2001 06:08:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA20646 for tcp-impl-outgoing; Sat, 17 Feb 2001 03:47:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id DAA20641; Sat, 17 Feb 2001 03:47:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA26586; Sat, 17 Feb 2001 03:47:02 -0500 Received: from chopin.cti.depaul.edu(140.192.32.73) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026565; Sat, 17 Feb 01 03:46:56 -0500 Received: from ehab2000 ([140.192.160.8]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.1600); Sat, 17 Feb 2001 02:46:38 -0600 Message-ID: <00a901c098be$42f1b980$08a0c08c@cti.depaul.edu> From: "Ehab Al-Shaer" To: "MMNS2001" Subject: CFP JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT Date: Sat, 17 Feb 2001 02:47:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 17 Feb 2001 08:46:39.0357 (UTC) FILETIME=[24B73AD0:01C098BE] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit CALL FOR PAPERS JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT Special Issue on Management of Converged Networks As the convergence of IP-based data and voice networks gets into the main stream of global networking business, many issues experienced earlier in the converged network infrastructure level, such as protocol interoperability, call server designs, Quality of Service (QoS) support, and service activation, will need management attention. The main focus of management of converged networks falls into two areas: (1) end-to-end network infrastructure manageability, and (2) activation, management, and accounting for integrated data and voice services. Challenges and opportunities exist in the areas such as policy-based QoS management, integrated subscriber management, call server management, management of converged data/voice directory services, multimedia multicast services, unified messaging services, customer care center services, and service information modeling. This special issue is intended to explore new challenges and solutions in the management of converged networks. Topics of interests for this special issue include the following: o Common management platform for converged IP and voice domains o Management of protocol interoperability (signaling, service control, and operations) across converged networks o Management of gateways and gatekeepers o Call server management and bandwidth brokerage o Management of converged networking infrastructure - IP/voice over ATM, DSL, CATV, SONET/SDH, and WDM o Policy-based QoS management and QoS interworking for converged networks (DiffServ, RSVP, MPLS) o Unified service-level information models o Converged services (unified messaging, customer care center, unified directory, multimedia services, etc.) and service interoperability between IP-based network and PSTN o Service configuration, provisioning and activation solutions o Service level agreement - contract negotiation, monitoring, and accounting o Enabling technologies for management of converged network (LDAP directory, XML, CORBA) Instructions to Contributors: We invite prospective authors to submit high quality papers via email to one of the guest editors, depending on their geographic locations. Only electronic submissions are acceptable. Manuscripts shall not exceed 25 double-spaced pages including figures and tables. Please prepare the manuscripts according to the Instructions to Contributors, which can be found in any copy of the Journal, or by visiting the JNSM Web site at http://www.cstp.umkc.edu/jnsm/. Guest Editors: Dr. Geng Lin (Contact for non-US submissions) Nortel Networks 4401 Great America Parkway Santa Clara, CA 95054 USA Email: genglin@nortelnetworks.com Prof. Chien-Chung Shen (Contact for US submissions) Dept. of Computer and Information Sciences University of Delaware 103 Smith Hall Newark, DE 19716 USA Email: cshen@cis.udel.edu Schedule: Manuscript due: April 30, 2001 Notification of Acceptance: July 31, 2001 Final Manuscript due: Sept. 30, 2001 Publication Date: 1st Quarter 2002 From owner-tcp-impl@lerc.nasa.gov Sat Feb 17 16:56:17 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07785 for ; Sat, 17 Feb 2001 16:56:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA20184 for tcp-impl-outgoing; Sat, 17 Feb 2001 14:26:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA20172; Sat, 17 Feb 2001 14:26:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA08420; Sat, 17 Feb 2001 14:26:22 -0500 Received: from louie.udel.edu(128.175.2.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008397; Sat, 17 Feb 01 14:25:27 -0500 Received: from galois.cis.udel.edu by mail.eecis.udel.edu id aa20868; 17 Feb 2001 14:22 EST Date: Sat, 17 Feb 2001 14:20:50 -0500 (EST) From: Constantinos Dovrolis To: Constantinos Dovrolis Subject: ICNP 2001 - Call for papers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk (you will probably receive this message multiple times.. my apologies) -------------------------------------------------------------------------- CALL FOR PAPERS -------------------------------------------------------------------------- 9th International Conference on Network Protocols (ICNP 2001) Mission Inn, Riverside, California November 11-14, 2001 http://www.cis.udel.edu/icnp2001/ In just eight years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, and implementation. Protocol functions of interest include network access, switching, routing, flow and congestion control, multimedia transport, wireless and mobile networks, network security, web protocols and applications, electronic commerce, network management, interoperability, internetworking, home computing and networks and digital broadcasting. ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place filled with history. Riverside is located in the Sunny Southern California, 60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from Disney Land. The city is served by three nearby airports: Los Angeles, Ontario (California) and Orange County Airport. Important Dates: Paper Submission Deadline: May 7, 2001 Notification of Acceptance: July 13, 2001 Camera Ready Due: August 8, 2001 Tutorials: November 11, 2001 Conference: November 12 - 14, 2001 General Chair Satish K. Tripathi, University of California - Riverside Technical Program Co-Chairs Magda El Zarki, University of California, Irvine Klara Narhstedt, University of Illinois, Urbana-Champaign Tutorial Co-Chairs Pravin Bhagwat, AT&T Research Ed Knightly, Rice University Local Arrangement and Registration Co-Chairs Michalis Faloutsos, University of California - Riverside Srikant Krishnamurthy, University of California - Riverside Publicity Co-Chairs Constantinos Dovrolis, University of Delaware Samar Singh, La Trobe University, Australia ICNP Steering Committee Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs ------------------------------------------------------------------ Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ From owner-tcp-impl@lerc.nasa.gov Mon Feb 26 15:36:26 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26418 for ; Mon, 26 Feb 2001 15:36:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA08723 for tcp-impl-outgoing; Mon, 26 Feb 2001 12:56:54 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA08687 for ; Mon, 26 Feb 2001 12:56:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA00740; Mon, 26 Feb 2001 12:56:46 -0500 Received: from mailhost.iprg.nokia.com(205.226.5.12) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000696; Mon, 26 Feb 01 12:56:26 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA06719 for ; Mon, 26 Feb 2001 09:56:25 -0800 (PST) From: Fred Bauer Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1QHuMV21361 for ; Mon, 26 Feb 2001 09:56:22 -0800 X-mProtect: Mon, 26 Feb 2001 09:56:22 -0800 Nokia Silicon Valley Messaging Protection Received: from vienna.iprg.nokia.com (205.226.11.35) by darkstar.iprg.nokia.com(WTS.12.69) smtpdDKgNWB; Mon, 26 Feb 2001 09:55:43 PST Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id JAA22494 for tcp-impl@lerc.nasa.gov; Mon, 26 Feb 2001 09:55:45 -0800 (PST) Date: Mon, 26 Feb 2001 09:55:45 -0800 (PST) Message-Id: <200102261755.JAA22494@vienna.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: Hot Interconnects 2001 CFP Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk CALL FOR PAPERS HOT INTERCONNECTS 9 A Symposium on High Performance Interconnects Memorial Auditorium, Stanford University, Aug. 22-24, 2001 (Sponsored by the IEEE Computer Society) http://www.hoti.org Hot Interconnects is an international symposium focusing on the hardware and software architecture and implementation of high-performance interconnects of all scales. Its themes include cross-cutting issues spanning computer systems and networking technologies for providing universal services over packet networks. Examples of relevant topics include network-attached storage, transport of voice and video over packet networks, high-performance network interfaces, novel switching and routing technologies capable of providing differentiated services, plug-and-play network interfaces, and active network architectures. The conference is directed particularly at new and exciting product and technology innovations in these areas. Contributions should focus on real products, prototypes, or experimental systems and their performance evaluation. In addition to those subscribing to the main theme of the conference, contributions are also solicited on the following topics: - Gb/sec and Tb/sec switching and routing technologies - High-speed packet processing engines - Serial link technologies - xDSL, HFC, and wireless access technologies - Mobility-enabling technologies - Seamless appliance interconnectivity - Network-attached storage devices and interfaces - Video and voice over packet networks - Wireless and mobile network interfaces - Network security - Next-generation networking chip sets - Network protocols on a chip - Low-power networking and interconnect technologies - Network appliance technologies - Optical Interconnects Submission Guidelines: --------------------------------- Submissions must be in the form of extended summaries and should not exceed 5 pages (double-column format). The summary should have sufficient technical detail to judge its quality and suitability for presentation at the conference. Guidelines for submission are available at http://www.hoti.org. Inquires about the conference should be directed to the TPC chairs. Important Dates: ----------------------- - Submission deadline: April 15, 2001. - Notification of acceptance: May 15, 2001. - Camera-ready due: July 1, 2001. Organizing Committee: --------------------------------- - General Chair: Fred Bauer, Nokia (fred@iprg.nokia.com) - Technical Program Chairs: - Marwan Krunz, University of Arizona (krunz@ece.arizona.edu) - John Lockwood, Washington University at St. Louis (lockwood@arl.wustl.edu) - Tutorial/Panel: Ibrahim Matta, Boston University (matta@cs.bu.edu) - Treasurer: Melanie Swan, MS Financial Consulting (melanie.swan@wharton.upenn.edu) - Registration: Bob Wedig, Wedig Consulting (bob@wedig.com) - Webmaster: Raymond Lee, IP Dynamics (raymondl@ipdynamics.com) - Local arrangements: Liz Rogers, Liz Rogers Design (liz@lizrogersdesign.com) - Publicity: TBD Technical Program Committee: TBD