This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: CloseSocket() problem


I'd use wget or the w3 consortium reference client to perform some tests and see if you can isolate the behaviour to a specific
timing issue/set of circumstances.

ie does the outstanding data need to be > 5K
does the behaviour occur with netscape?
Does ie have http1.1 or 1.0 turned on for the client-proxy connection?

Other than that, grabbing the squid 2.4 source (Get the current nightly snapshot) and comparing the socket code to yours.

On another note, if your WWWOFFLE has code to read the DNS servers from the win32 config (on 95/98/Me/NT & 2K) I'd be really
interested in getting that into squid.

Rob

----- Original Message -----
From: "David McNab" <david@rebirthing.co.nz>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Sent: Friday, January 05, 2001 3:18 PM
Subject: Re: CloseSocket() problem


> Hi Rob,
>
> Thanks for your unexpectedly fast reply.
>
> I tried doing a setsockopt() to put the socket to the browser in linger
> mode, with a 5 second timeout, immediately before the close() call.
> It appeared to make no difference. I enclose a code excerpt at the end of
> the email.
>
> By the way, it's a forked child process that's interacting with the socket
> connection to the browser.
>
> Can you offer any further suggestions?
>
> Regards
> David McNab
>
> #ifndef TRY_A_LINGERING_CLOSE
>  {
>   struct linger lingeropt;
>
>   lingeropt.l_onoff = 1;
>   lingeropt.l_linger = 15;
>
>   if (setsockopt(client, SOL_SOCKET, SO_LINGER, &lingeropt,
> sizeof(lingeropt)) < 0)
>   {
>    switch errno
>    {
>    case EBADF:
>     PrintMessage(Important, "setsockopt error: EBADF");
>     break;
>    case ENOTSOCK:
>     PrintMessage(Important, "setsockopt error: ENOTSOCK");
>     break;
>    case ENOPROTOOPT:
>     PrintMessage(Important, "setsockopt error: ENOPROTOPT");
>     break;
>    default:
>     PrintMessage(Important, "setsockopt: unknown error");
>    }
>   }
>   else
>    PrintMessage(Important, "setsockopt succeeded");
>  }
> #endif
>  sleep(3);
>     CloseSocket(client);
>  }
>
>
> ----- Original Message -----
> From: "Robert Collins" <robert.collins@itdomain.com.au>
> To: "David McNab" <david@rebirthing.co.nz>; <cygwin@cygwin.com>
> Sent: Wednesday, January 03, 2001 10:42 PM
> Subject: Re: CloseSocket() problem
>
>
> > David,
> >     I suspect you are seeing an issue that is TCP/IP spec related, not
> cygwin related. (I have squid 2.4 running on cygwin in
> > several locations, without any sign of the symptoms you have). However
> your symptoms sound similar to those faced by Apache and
> > Squid with half closed connections. Due to tcp/ip's close sequence, and
> also to general delay between send and acknowledgement of
> > receipt, you cannot know that the browser has receieved the data just
> because you have written it to the socket.
> >
> > Apache used a technique called lingering closes to solve this. You might
> consider looking into that.
> >
> > On the other hand I could be completely off base here :-]
> >
> > Rob
> >
> > ----- Original Message -----
> > From: "David McNab" <david@rebirthing.co.nz>
> > To: <cygwin@cygwin.com>
> > Cc: "Andrew M. Bishop" <amb@gedanken.demon.co.uk>
> > Sent: Friday, January 05, 2001 12:54 PM
> > Subject: CloseSocket() problem
> >
> >
> > > Hi Corinna,
> > >
> > > On searching through Cygwin mail archives, I note that you've had
> problems
> > > with closing down sockets in child processes.
> > >
> > > I have experienced the same thing. I'm presently working on testing the
> > > Win32 Cygwin port of another developer's proxy server program (called
> > > WWWOFFLE, see http://www.gedanken.demon.co.uk/wwwoffle/).
> > >
> > > On re-compiling the program with the cygwin v1.1.7.1 dll, I noticed
> > > Microsoft Internet Explorer complaining that the server connections had
> been
> > > reset.
> > >
> > > I have added code to the applicable child process which fcntl()'s the
> client
> > > socket to blocking mode, then writes a byte of data. This is an attempt
> to
> > > ensure that all data send()'ed to Internet Explorer has actually been
> sent
> > > prior to the CloseSocket(). This hack seems to improve things
> dramatically,
> > > but the problem still shows when sending larger volumes of data back to
> > > Internet Explorer.
> > >
> > > Can you please advise on the status of this CloseSocket() problem, and
> > > 1) Any suggestions for a workaround, and/or
> > > 2) Whether there are any interim fixes available
> > >
> > > Kindest thanks in advance
> > > David McNab
> > > david@rebirthing.co.nz
> > >
> > >
> > >
> > > --
> > > Want to unsubscribe from this list?
> > > Check out: http://cygwin.com/ml/#unsubscribe-simple
> > >
> > >
> >
> >
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]