Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!RIMFAXE.DIKU.DK!thorinn From: thorinn@RIMFAXE.DIKU.DK (Lars Henrik Mathiesen) Newsgroups: comp.protocols.tcp-ip.domains Subject: problems with nsfnet-relay.ac.uk Message-ID: <9103021528.AA09106@rimfaxe.diku.dk> Date: 2 Mar 91 15:28:21 GMT References: <1666.667855170@xtel.co.uk> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 24 From: Julian Onions Spot on. The nsfnet relay machine ... is configured to allow 10 simultaneous connections - and there is nearly always that number connected. No need for sinister theories, 1 days outage is enough to build up a huge queue of messages inbound and outbound. As I read that, it means that the SMTP server will stop accepting new connections once the maximum number is reached, even though it could do so. That is *wrong*, it should accept the connection, send a 421 reply code (service unavailable), and close the connection. (It wouldn't even have to create an extra process to do that, it could be done in the main loop.) This would 1) let the sender defer the letter at once, 2) save some retransmitted SYN packets, 3) save some kernel memory on nsfnet-relay for waiting TCP connections, and 4) be nice. (Also, now there will always be about 8 established connections in a kernel queue, waiting for the SMTP server to accept them. That's not nice either.) -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk