From martin@ndl.co.uk Wed Dec 8 15:48:27 1993 Received: from relay1.pipex.net by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA10656; Wed, 8 Dec 1993 10:47:34 -0500 Received: from jalfrezi.ndl.co.uk by relay1.pipex.net with SMTP (PP) id <22372-0@relay1.pipex.net>; Wed, 8 Dec 1993 15:47:31 +0000 Received: from PALADIN (paladin.ndl.co.uk) by jalfrezi.ndl.co.uk (4.1/SMI-4.1) id AA02998; Wed, 8 Dec 93 15:47:35 GMT Message-Id: <9312081547.AA02998@jalfrezi.ndl.co.uk> X-Sender: martin@mailhost.ndl.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 Dec 1993 15:48:27 +0000 To: winsock-hackers@sunsite.unc.edu From: martin@ndl.co.uk (Martin J Norman) Subject: Microsoft Winsock abd debug X-Mailer: Question, does Microsofts winsock stack support debug mode (SO_DEBUG)? And if it does what information can got from it? Martin. Development. Network Designers Ltd. Not an official spokesperson. From ICH211@ZAM001.ZAM.KFA-JUELICH.DE Thu Dec 9 13:01:45 1993 Received: from zam001.zam.kfa-juelich.de by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA11249; Thu, 9 Dec 1993 06:06:01 -0500 Message-Id: <199312091106.AA11249@SunSITE.Unc.EDU> Received: from DJUKFA11 by ZAM001.ZAM.KFA-JUELICH.DE (IBM VM SMTP V2R2) with BSMTP id 2720; Thu, 09 Dec 93 12:04:37 +0100 Date: Thu, 09 Dec 93 12:01:45 +0100 From: Thomas Heil Organization: Forschungszentrum Juelich GmbH - Institut fuer Chemie 2 Subject: How to reset conn. with LWP winsock (SO_LINGER unchangeable) To: winsock-hackers@sunsite.unc.edu Hello! Perhaps someone can enlighten me: Novell's LanWorkPlace WINSOCK.DLL does not allow the changing of the SO_LINGER socket option (it's defaulted to SO_DONTLINGER, and that's the way it stays). So ... how can I reset a connection when using this implementation (which is normally done by setting SO_LINGER with a zero timeout)? /Thomas ---------------------------------------+-------------------------------------- Mail: Thomas Heil | EMail: BITNET: ICH211@DJUKFA11.BITNET Forschungszentrum Juelich - ICG2 | Internet: th.heil@kfa-juelich.de 52425 Juelich | Phone: +49 2461 61-6915 Germany | Fax: +49 2461 61-5346 From paul@atlas.dev.abccomp.oz.au Mon Dec 13 04:21:10 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA08119; Sun, 12 Dec 1993 17:10:47 -0500 Received: by usage.csd.unsw.OZ.AU id AA04744 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 13 Dec 1993 09:10:45 +1100 Received: by atlas (4.1/1.35) id AA18486; Mon, 13 Dec 93 09:21:10 EST Date: Mon, 13 Dec 93 09:21:10 EST From: paul@atlas.abccomp.oz.au (Paul Brooks) Message-Id: <9312122221.AA18486@atlas> To: phe@farallon.com Subject: Re: Valid socket Newsgroups: alt.winsock In-Reply-To: Organization: TurboSoft Pty Ltd, Sydney, Australia Cc: winsock-hackers@sunsite.unc.edu In article you write: |Hi: | |INVALID_SOCKET is defined as (SOCKET)(~0). Is the value 0 a valid socket? I |have checked some winsock implementions. They all seemed to start from 1 to |whatever. >From my reading of the spec, yes, 0 is a valid number for a socket. The ONLY value not allowed for a socket is ~0, which is defined that way because a SOCKET is unsigned, so '-1' is not a valid value. In binary, -1 and ~0 both contain all '1' bits. Note that the value of sockets need not be integers starting from '1'. It is perfectly possible that some implementations will use other types of identifiers for sockets, such as near pointers to a descripter block, or even far pointers in 32-bit versions. You cannot rely on SOCKET values being simple positive integers, and testing the return result for being ' <0 ' like much ported Unix code does will bite you badly. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From phe@farallon.com Fri Dec 13 00:55:46 1993 Received: from farallon.com (farallon.farallon.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA17677; Mon, 13 Dec 1993 09:53:28 -0500 Received: from waygate.farallon.com ([163.176.8.12]) by farallon.com (4.1/SMI-4.1) id AA11379; Mon, 13 Dec 93 06:53:06 PST Message-Id: <9312131453.AA11379@farallon.com> Date: 13 Dec 1993 08:55:46 -0800 From: "Ping He" Subject: RE: Valid socket Return-Receipt-To: "Ping He" To: "Paul Brooks" Cc: winsock-hackers@sunsite.unc.edu Thank you for your info. Ping _______________________________________________________________________________ To: Ping He Cc: winsock-hackers@sunsite.unc.edu From: Paul Brooks on Sun, Dec 12, 1993 2:10 PM Subject: Re: Valid socket RFC Header:Received: by waygate.farallon.com with SMTP;12 Dec 1993 14:10:29 -0800 Received: from usage.csd.unsw.OZ.AU by farallon.com (4.1/SMI-4.1) id AA08359; Sun, 12 Dec 93 14:10:41 PST Received: by usage.csd.unsw.OZ.AU id AA04744 (5.65c/IDA-1.4.4 for phe%farallon.com); Mon, 13 Dec 1993 09:10:45 +1100 Received: by atlas (4.1/1.35) id AA18486; Mon, 13 Dec 93 09:21:10 EST Date: Mon, 13 Dec 93 09:21:10 EST From: paul@atlas.abccomp.oz.au (Paul Brooks) Message-Id: <9312122221.AA18486@atlas> To: ping_he.kansas_mail@waygate Subject: Re: Valid socket Newsgroups: alt.winsock In-Reply-To: Organization: TurboSoft Pty Ltd, Sydney, Australia Cc: winsock-hackers@sunsite.unc.edu In article you write: |Hi: | |INVALID_SOCKET is defined as (SOCKET)(~0). Is the value 0 a valid socket? I |have checked some winsock implementions. They all seemed to start from 1 to |whatever. >From my reading of the spec, yes, 0 is a valid number for a socket. The ONLY value not allowed for a socket is ~0, which is defined that way because a SOCKET is unsigned, so '-1' is not a valid value. In binary, -1 and ~0 both contain all '1' bits. Note that the value of sockets need not be integers starting from '1'. It is perfectly possible that some implementations will use other types of identifiers for sockets, such as near pointers to a descripter block, or even far pointers in 32-bit versions. You cannot rely on SOCKET values being simple positive integers, and testing the return result for being ' <0 ' like much ported Unix code does will bite you badly. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Tue Dec 14 12:45:34 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP From dob@tis.inel.gov Tue Dec 14 01:12:44 1993 Received: from mica.inel.gov by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA10511; Tue, 14 Dec 1993 10:12:17 -0500 Received: from dewey.inel.gov (dewey.tis.inel.gov) by mica.inel.gov (4.1/INEL-MH-10.0) id AA01804; Tue, 14 Dec 93 08:11:51 MST Received: by dewey.inel.gov (5.65/INEL-WKS-2.0) id AA06191; Tue, 14 Dec 1993 08:12:44 -0700 Date: Tue, 14 Dec 1993 08:12:44 -0700 From: dob@tis.inel.gov (Dave Brooks) Message-Id: <9312141512.AA06191@dewey.inel.gov> To: paul@atlas.abccomp.oz.au, winsock-hackers@sunsite.unc.edu Subject: action on connection to full listening queue In-Reply-To: <9312140645.AA24607@atlas> References: <9312140645.AA24607@atlas> paul@atlas.abccomp.oz.au writes: > I've been on BSD-patrol again trying to reconcile some small differences in > described bahaviour, and call for comments on this one: Good deal, Paul. > The Windows Sockets spec states that when a connection attempt arrives for > a socket which is listening, and has filled its backlog, the connection > attempt will be returned, and the connecting socket will return > error WSAECONNREFUSED. > The man-page for listen on our SunOS 4.1 box says the same thing. > > The document "An Advanced Socket-Based Interprocess Communications > Tutorial" from Sun, however, states: > [ alternative behavior deleted] > My gut feel tells me the man-page and Windows Sockets description are > the appropriate way to go, although I can see merit in the alternative > behaviour. > > The question is, which is the "correct" bahaviour, according to > Berkeley Sockets tradition? There is merit in the alternative, but it's not "correct" according to the WinSock spec or my understanding and experience with the BSD tradition. OTOH, I've never seen a user respond positively to a "failure to connect". Dave From ed@odi.com Tue Dec 14 06:10:00 1993 Received: from mineshaft.odi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA17457; Tue, 14 Dec 1993 11:10:14 -0500 Received: from odi.com (kayak.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA12556; Tue, 14 Dec 1993 11:10:01 -0500 Return-Path: Received: by odi.com (4.1/SMI-4.0/ODI-15) id AA29535; Tue, 14 Dec 93 11:10:00 EST Date: Tue, 14 Dec 93 11:10:00 EST From: Ed Schwalenberg Message-Id: <9312141610.AA29535@odi.com> To: dob@tis.inel.gov Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: Dave Brooks's message of Tue, 14 Dec 1993 10:14:33 -0500 <9312141512.AA06191@dewey.inel.gov> Subject: action on connection to full listening queue Date: Tue, 14 Dec 1993 10:14:33 -0500 From: dob@tis.inel.gov (Dave Brooks) > The Windows Sockets spec states that when a connection attempt arrives for > a socket which is listening, and has filled its backlog, the connection > attempt will be returned, and the connecting socket will return > error WSAECONNREFUSED. > The man-page for listen on our SunOS 4.1 box says the same thing. OTOH, I've never seen a user respond positively to a "failure to connect". Indeed. On the other hand, if an operating system kernel or a Windows Sockets implementation were to use up infinite resources in an attempt to queue up an infinite number of connections, the user at the listening end would probably be just as unhappy as his peer who's attempting to connect. That's why listen() has a backlog argument. What I don't understand is why certain operating systems think that 5 is an acceptable number for the maximum possible backlog. Virtually every customer we've ever had stress-tests our client-server database product by starting up a zillion simultaneous clients; on the operating systems in question some number of clients fail because our attempt to do listen(x, 100) failed. From davidtr@microsoft.com Tue Dec 14 02:12:00 1993 Received: from netmail.microsoft.com ([131.107.1.13]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA15315; Tue, 14 Dec 1993 14:39:11 -0500 Received: by netmail.microsoft.com (5.65/25-eef) id AA11351; Tue, 14 Dec 93 11:39:36 -0800 Message-Id: <9312141812.AA02663@itgmsm> From: davidtr@microsoft.com To: winsock-hackers@SunSITE.Unc.EDU Subject: RE: action on connection to full listening queue Date: Tue, 14 Dec 93 10:12:00 PST X-Mailer: Microsoft Mail V3.0 |From: netmail!paul@atlas.abccomp.oz.au | |The Windows Sockets spec states that when a connection attempt arrives for |a socket which is listening, and has filled its backlog, the connection |attempt will be returned, and the connecting socket will return |error WSAECONNREFUSED. | The man-page for listen on our SunOS 4.1 box says the same thing. | | The document "An Advanced Socket-Based Interprocess Communications |Tutorial" from Sun, however, states: | "Should a connection be requested while the queue is full, the |conection will not be refused, but rather the individual messages that |comprise the request will be ignored. This gives the harried server time |to make room in its pending connection queue while the client retries the |connection request. Had the connection been returned with the ECONNREFUSED |error, the client would be unable to tell if the server was up or not." | |My gut feel tells me the man-page and Windows Sockets description are |the appropriate way to go, although I can see merit in the alternative |behaviour. | | The question is, which is the "correct" bahaviour, according to |Berkeley Sockets tradition? i see this as really a TCP question. if a host receives a SYN for a listening port which has reached the backlog limit, should the host respond with a RST or should it ignore the SYN? i scanned rfcs 793 and 1122 but couldn't find an answer for this. of the implementations i'm aware of, all send the RST, but they also retry the SYN in response to a RST to smooth over the case where the backlog is full, so the ECONNREFUSED as a result of a full backlog is very rare--it would require that the backlog be full for an extended period of time. the disadvantage of ignoring the SYN is that the client does not know get any acknowledgement that a path to the host exists. davidtr@microsoft.com From paul@atlas.dev.abccomp.oz.au Wed Dec 15 04:31:18 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA05117; Tue, 14 Dec 1993 17:58:38 -0500 Received: by usage.csd.unsw.OZ.AU id AA16631 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 15 Dec 1993 09:20:53 +1100 Received: by atlas (4.1/1.35) id AA27288; Wed, 15 Dec 93 09:31:18 EST Message-Id: <9312142231.AA27288@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 15 Dec 1993 09:31:18 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: ed@odi.com, Multiple recipients of list Subject: Re: action on connection to full listening queue Thus expounded Ed Schwalenberg on Dec 14,11:12am: /-------------------- | Date: Tue, 14 Dec 1993 10:14:33 -0500 | From: dob@tis.inel.gov (Dave Brooks) | | > The Windows Sockets spec states that when a connection attempt arrives for | > a socket which is listening, and has filled its backlog, the connection | > attempt will be returned, and the connecting socket will return | > error WSAECONNREFUSED. | > The man-page for listen on our SunOS 4.1 box says the same thing. | | OTOH, I've never seen a user respond positively to a "failure to connect". | |What I don't understand is why certain operating systems think that 5 is |an acceptable number for the maximum possible backlog. Virtually every |customer we've ever had stress-tests our client-server database product by |starting up a zillion simultaneous clients; on the operating systems in |question some number of clients fail because our attempt to do listen(x, 100) |failed. Are you re-tranmsitting the SYN despite receiving one or two RST segments, as the fine print in RFC1122 seems to indicate? (see my reply to David) This would cause your client to wait a little longer, hopefully getting in when your server has serviced a couple of the lucky early connections. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Wed Dec 15 04:27:12 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA05152; Tue, 14 Dec 1993 17:58:55 -0500 Received: by usage.csd.unsw.OZ.AU id AA16497 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 15 Dec 1993 09:16:45 +1100 Received: by atlas (4.1/1.35) id AA27282; Wed, 15 Dec 93 09:27:13 EST Message-Id: <9312142227.AA27282@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 15 Dec 1993 09:27:12 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: davidtr@microsoft.com, Multiple recipients of list Subject: RE: action on connection to full listening queue Thus expounded davidtr@microsoft.com on Dec 14, 2:45pm: /-------------------- ||From: netmail!paul@atlas.abccomp.oz.au || ||The Windows Sockets spec states that when a connection attempt arrives for ||a socket which is listening, and has filled its backlog, the connection ||attempt will be returned, and the connecting socket will return ||error WSAECONNREFUSED. || The man-page for listen on our SunOS 4.1 box says the same thing. || || The document "An Advanced Socket-Based Interprocess Communications ||Tutorial" from Sun, however, states: || "Should a connection be requested while the queue is full, the ||conection will not be refused, but rather the individual messages that ||comprise the request will be ignored. This gives the harried server time ||to make room in its pending connection queue while the client retries the ||connection request. Had the connection been returned with the ECONNREFUSED ||error, the client would be unable to tell if the server was up or not." || ||My gut feel tells me the man-page and Windows Sockets description are ||the appropriate way to go, although I can see merit in the alternative ||behaviour. || || The question is, which is the "correct" bahaviour, according to ||Berkeley Sockets tradition? | |i see this as really a TCP question. if a host receives a SYN for a |listening port which has reached the backlog limit, should the host respond |with a RST or should it ignore the SYN? i scanned rfcs 793 and 1122 but |couldn't find an answer for this. of the implementations i'm aware of, all |send the RST I take the view that a listening socket with a backlog of 'x' is just 'x' sockets waiting for a connection. Since a listening socket automatically replies and establishes the connection into the fully opened state, it is no longer 'listening', so when the backlog is full there are no more passive sockets waiting for a connection, so send a RST just as you would if you had no listener on the port at all. This I guess is the logic that causes all implementations to return RST. , but they also retry the SYN in response to a RST to smooth |over the case where the backlog is full, so the ECONNREFUSED as a result of |a full backlog is very rare--it would require that the backlog be full for |an extended period of time. This is actually covered in RFC1122, page 101 I think: "An attempt to open a TCP connection could fail with excessive retransmissions of the SYN segment or by receipt of a RST segment or an ICMP Port Unreachable. SYN retransmissions MUST be handled in the general way just described for data re-transmissions..." which to me basically means a connect() shold keep sending SYNs even if it keeps getting RST segments back, at least for a reasonable number of times. In fact, it would make sense to ignore return RSTs for SYNs in this case, so the re-transmission logic automatically handles backing off the retransmission interval for the SYN. Just record the fact that a RST or ICMP Port Unreachable was encountered, so then the SYN fails with excessive re-transmissions the error code ECONNREFUSED instead of ETIMEDOUT is returned. This, of course, leads to exactly the same effect as ignoring the incoming SYN if the backlog is full, in the hope that the backlog will clear so that a re-transmitted SYN will be accepted, except for the fact, as David notes below, that in this case you have no indication of whether the SYNs reached the target or not when the attempt times out. |the disadvantage of ignoring the SYN is that the client does not know get |any acknowledgement that a path to the host exists. | |davidtr@microsoft.com \--------------------- {end} All these are really TCP implementation questions rather than Sockets-related issues, and the guiding principle with Windows Sockets is to "do unto others what BSD does unto you", so we'll go with the RST and returning WSAECONNREFUSED as described in the spec. and listen() BSD man- pages. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Wed Dec 15 12:54:11 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA10793; Wed, 15 Dec 1993 01:43:48 -0500 Received: by usage.csd.unsw.OZ.AU id AA04617 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 15 Dec 1993 17:43:35 +1100 Received: by atlas (4.1/1.35) id AA29101; Wed, 15 Dec 93 17:54:11 EST Message-Id: <9312150654.AA29101@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 15 Dec 1993 17:54:11 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: multiple connect() attempts on a single socket Question: If a connect() attempt fails for some reason after it has sent network traffic (e.g. failure returns WSAETIMEDOUT or WSAECONNREFUSED), is it necessary to support multiple subsequent connect() attempts, or must the socket be closed then re-opened again. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From dave@auspost.com.au Wed Dec 22 21:48:52 1993 Received: from yarrina.connect.com.au by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA13341; Tue, 21 Dec 1993 19:01:12 -0500 Received: by yarrina.connect.com.au with UUCP id AA06157 (5.67b8/IDA-1.5 for winsock-hackers@sunsite.unc.edu); Wed, 22 Dec 1993 11:01:04 +1100 Received: from dross.auspost.com.au (dross) by guk.auspost.com.au with SMTP id AA25283 (5.65c/IDA-1.4.4); Wed, 22 Dec 1993 10:53:46 +1100 Received: by dross.auspost.com.au id AA26724 (5.65c/IDA-1.4.4); Wed, 22 Dec 1993 10:48:52 +1100 Date: Wed, 22 Dec 1993 10:48:52 +1100 From: Dave Cole Message-Id: <199312212348.AA26724@dross.auspost.com.au> To: paul@atlas.abccomp.oz.au Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <9312212250.AA24350@atlas> (paul@atlas.abccomp.oz.au) Subject: Re: non-blocking connect() timeout after program exits > How are you making the socket non-blocking - using ioctlsocket() or > WSAAsyncSelect() - and if the latter, you could try calling > WSAAsyncSelect with an argument lEvent=0L to cancel your interest > in asynchronous events before closing the socket. You shouldn't > have to do this, but it might get you going until the stack > is fixed. I never thought of making the socket non-blocking by using WSAAsyncSelect()... I wonder... I will be a bit annoyed if the stack is able to cancel the connect if I use WSAAsyncSelect() but not if I use ioctlsocket(). Thanks for your suggestion. - Dave From paul@atlas.dev.abccomp.oz.au Wed Dec 22 04:50:06 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA16999; Tue, 21 Dec 1993 19:59:52 -0500 Received: by usage.csd.unsw.OZ.AU id AA29715 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 22 Dec 1993 10:25:05 +1100 Received: by atlas (4.1/1.35) id AA24350; Wed, 22 Dec 93 09:50:06 EST Date: Wed, 22 Dec 93 09:50:06 EST From: paul@atlas.abccomp.oz.au (Paul Brooks) Message-Id: <9312212250.AA24350@atlas> To: dave@auspost.com.au, winsock-hackers@sunsite.unc.edu Subject: Re: non-blocking connect() timeout after program exits Newsgroups: alt.winsock In-Reply-To: Organization: TurboSoft Pty Ltd, Sydney, Australia In article you write: |My setup: Windows 4 Workgroups TCP/IP | |My problem: I create a non-bocking socket, the fire off a connect to |the unix based server. if the server is not running on the unix box, |the connect times out. If I exit my program, before the timeout, |going though all of the required shutdown; when the connect() times |out, I am dumped back at the DOS prompt. | |Has anyone else seen this? How are you making the socket non-blocking - using ioctlsocket() or WSAAsyncSelect() - and if the latter, you could try calling WSAAsyncSelect with an argument lEvent=0L to cancel your interest in asynchronous events before closing the socket. You shouldn't have to do this, but it might get you going until the stack is fixed. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From junodj@gordon-css583.army.mil Thu Dec 30 13:36:18 1993 Received: from gordon-css583.army.mil ([192.108.177.3]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA02487; Thu, 30 Dec 1993 18:45:08 -0500 Message-Id: <199312302345.AA02487@SunSITE.Unc.EDU> Date: Thu, 30 Dec 93 18:36:18 EST From: MSG Junod John To: winsock-hackers@sunsite.unc.edu Subject: connect timeout Maybe this has been covered before, but how do you increase the timeout on a "connect" call? Is there a standard way in winsock to do this? John From nervmaster.pad@sni.de Thu Dec 30 19:01:37 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA04076; Thu, 30 Dec 1993 19:01:37 -0500 Message-Id: <199312310001.AA04076@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <02091-0@mail.sni.de>; Fri, 31 Dec 1993 01:00:51 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 1:01:19 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 19:18:47 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA05796; Thu, 30 Dec 1993 19:18:47 -0500 Message-Id: <199312310018.AA05796@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <03092-0@mail.sni.de>; Fri, 31 Dec 1993 01:18:03 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 1:18:33 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 19:41:58 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA08231; Thu, 30 Dec 1993 19:41:58 -0500 Message-Id: <199312310041.AA08231@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <04653-0@mail.sni.de>; Fri, 31 Dec 1993 01:41:07 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 1:41:37 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 19:59:32 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA09803; Thu, 30 Dec 1993 19:59:32 -0500 Message-Id: <199312310059.AA09803@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <05619-0@mail.sni.de>; Fri, 31 Dec 1993 01:58:43 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 1:59:12 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 20:17:23 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA11397; Thu, 30 Dec 1993 20:17:23 -0500 Message-Id: <199312310117.AA11397@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <06840-0@mail.sni.de>; Fri, 31 Dec 1993 02:16:38 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 2:17:06 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 20:49:51 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA13877; Thu, 30 Dec 1993 20:49:51 -0500 Message-Id: <199312310149.AA13877@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <08484-0@mail.sni.de>; Fri, 31 Dec 1993 02:49:07 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 2:49:35 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 21:31:13 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA17844; Thu, 30 Dec 1993 21:31:13 -0500 Message-Id: <199312310231.AA17844@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <09956-0@mail.sni.de>; Fri, 31 Dec 1993 03:30:30 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 3:30:53 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 21:52:11 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA20024; Thu, 30 Dec 1993 21:52:11 -0500 Message-Id: <199312310252.AA20024@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <10403-0@mail.sni.de>; Fri, 31 Dec 1993 03:51:27 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 3:51:54 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 22:16:51 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA21815; Thu, 30 Dec 1993 22:16:51 -0500 Message-Id: <199312310316.AA21815@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <10943-0@mail.sni.de>; Fri, 31 Dec 1993 04:16:03 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 4:16:32 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 22:37:38 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA23200; Thu, 30 Dec 1993 22:37:38 -0500 Message-Id: <199312310337.AA23200@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <11459-0@mail.sni.de>; Fri, 31 Dec 1993 04:36:48 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 4:37:17 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 22:58:17 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA24574; Thu, 30 Dec 1993 22:58:17 -0500 Message-Id: <199312310358.AA24574@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <11812-0@mail.sni.de>; Fri, 31 Dec 1993 04:57:33 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 4:58:01 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 23:18:48 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA25837; Thu, 30 Dec 1993 23:18:48 -0500 Message-Id: <199312310418.AA25837@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <12202-0@mail.sni.de>; Fri, 31 Dec 1993 05:18:04 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 5:18:33 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 23:38:44 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA27021; Thu, 30 Dec 1993 23:38:44 -0500 Message-Id: <199312310438.AA27021@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <12728-0@mail.sni.de>; Fri, 31 Dec 1993 05:38:00 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 5:38:29 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Thu Dec 30 23:58:41 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA28137; Thu, 30 Dec 1993 23:58:41 -0500 Message-Id: <199312310458.AA28137@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <13100-0@mail.sni.de>; Fri, 31 Dec 1993 05:57:52 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 5:58:21 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 00:19:45 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA29651; Fri, 31 Dec 1993 00:19:45 -0500 Message-Id: <199312310519.AA29651@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <13565-0@mail.sni.de>; Fri, 31 Dec 1993 06:19:01 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 6:19:30 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 00:40:22 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA00605; Fri, 31 Dec 1993 00:40:22 -0500 Message-Id: <199312310540.AA00605@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <14213-0@mail.sni.de>; Fri, 31 Dec 1993 06:39:37 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 6:40:06 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 01:01:36 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA01562; Fri, 31 Dec 1993 01:01:36 -0500 Message-Id: <199312310601.AA01562@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <14761-0@mail.sni.de>; Fri, 31 Dec 1993 07:00:41 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 7:01:11 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 01:22:54 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA02489; Fri, 31 Dec 1993 01:22:54 -0500 Message-Id: <199312310622.AA02489@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <15164-0@mail.sni.de>; Fri, 31 Dec 1993 07:21:43 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 7:22:12 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 01:42:45 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA03340; Fri, 31 Dec 1993 01:42:45 -0500 Message-Id: <199312310642.AA03340@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <15872-0@mail.sni.de>; Fri, 31 Dec 1993 07:41:52 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 7:42:21 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 02:02:33 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA04374; Fri, 31 Dec 1993 02:02:33 -0500 Message-Id: <199312310702.AA04374@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <16157-0@mail.sni.de>; Fri, 31 Dec 1993 08:01:46 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 8:02:14 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 02:21:57 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA05070; Fri, 31 Dec 1993 02:21:57 -0500 Message-Id: <199312310721.AA05070@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <16448-0@mail.sni.de>; Fri, 31 Dec 1993 08:21:12 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 8:21:40 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 02:58:54 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA06321; Fri, 31 Dec 1993 02:58:54 -0500 Message-Id: <199312310758.AA06321@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <17299-0@mail.sni.de>; Fri, 31 Dec 1993 08:58:10 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 8:58:39 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 03:18:43 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA07146; Fri, 31 Dec 1993 03:18:43 -0500 Message-Id: <199312310818.AA07146@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <17780-0@mail.sni.de>; Fri, 31 Dec 1993 09:17:59 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 9:18:28 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 03:43:49 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA08045; Fri, 31 Dec 1993 03:43:49 -0500 Message-Id: <199312310843.AA08045@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <18336-0@mail.sni.de>; Fri, 31 Dec 1993 09:43:05 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 9:43:34 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 04:08:15 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA08763; Fri, 31 Dec 1993 04:08:15 -0500 Message-Id: <199312310908.AA08763@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <18852-0@mail.sni.de>; Fri, 31 Dec 1993 10:07:31 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 10:08:00 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 04:26:39 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA09213; Fri, 31 Dec 1993 04:26:39 -0500 Message-Id: <199312310926.AA09213@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <19208-0@mail.sni.de>; Fri, 31 Dec 1993 10:25:56 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 10:26:25 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 04:44:57 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA09737; Fri, 31 Dec 1993 04:44:57 -0500 Message-Id: <199312310944.AA09737@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <19636-0@mail.sni.de>; Fri, 31 Dec 1993 10:44:13 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 10:44:42 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 05:13:09 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AB10512; Fri, 31 Dec 1993 05:13:09 -0500 Message-Id: <199312311013.AB10512@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <20189-0@mail.sni.de>; Fri, 31 Dec 1993 11:12:25 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 11:12:53 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 05:37:00 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA11158; Fri, 31 Dec 1993 05:37:00 -0500 Message-Id: <199312311037.AA11158@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <20855-0@mail.sni.de>; Fri, 31 Dec 1993 11:36:16 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 11:36:45 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: ------------------------- From nervmaster.pad@sni.de Fri Dec 31 05:57:48 1993 Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA11791; Fri, 31 Dec 1993 05:57:48 -0500 Message-Id: <199312311057.AA11791@SunSITE.Unc.EDU> Received: from sni.de by mail.sni.de id <21304-0@mail.sni.de>; Fri, 31 Dec 1993 11:57:04 +0100 Subject: Cannot mail to harms.pad. To: winsock-hackers@SunSITE.Unc.edu Date: Fri, 31 Dec 93 11:57:33 MET From: George Turnbull X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Cannot mail to harms.pad, empty mail. ----------------- Unsent message follows: -------------------------