Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: "Markus Hoenicka" <Markus DOT Hoenicka AT uth DOT tmc DOT edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14933.5970.809000.373411@gargle.gargle.HOWL>
Date: Fri, 5 Jan 2001 00:37:38 +0000 (CT0)
To: cygwin AT cygwin DOT com
Subject: CYGWIN Socket write() problem in 1.1.7 DLL
In-Reply-To: <009001c0775b$50b14ce0$574bb4ca@private>
References: <009001c0775b$50b14ce0$574bb4ca AT private>

I'm afraid there's not much that I can contribute in your case. Back
then I had the following problem: I had a client-server app that
worked fine on Linux and on Cygwin until 1.1.4. Problems started in
1.1.5. The reason was, as you also found out, that the socket was
closed after writing the data before the recipient could read the
stuff. As I am programming both the server and the client, a simple
change of the communication protocol works around this problem
now.

My client-server app worked like this (somewhat simplified): client
sends query, server sends data. This may go for several cycles if
large amounts of data are involved, but in the end the server had the
final word. I use a forking server, i.e. the child handles the request
and exits after the final message to the client. This stopped working
in 1.1.5. All I did was to let the server child wait for an
acknowledgement by the client after sending the last hunk of data. The
clients are readline-based console applications that do not exit
immediately after completing a query, so they are alive long enough to
wait for the write() to go through.

This does not exactly solve the problem, but it works around it quite
nicely. I'm still wondering whether this qualifies as a CygWin bug as
I don't see this problem on Linux. If it really was only a timing
problem, then it should hit harder on Linux than on Cygwin.

Sorry that I can't be of more help.

Markus

David McNab writes:
 > I note from the message archives that people have had some problems with
 > CYGWIN-built apps writing to sockets.
 > 
 > In a nutshell, the problem is that data written to the socket doesn't always
 > make it to the recipient. When the CYGWIN-built program closes the socket
 > after the write(), the client at the other end gets a disconnect failure and
 > doesn't receive the data.
 > 
 > I've had the same problem. I'm helping with testing and debugging of a
 > CYGWIN-based (v1.1.1.7 dll) proxy server program, for which I run Microsoft
 > Internet Explorer as a client. On page fetches, Internet Explorer often
 > complains that the 'connection to the server was reset'.
 > 
 > Has anyone found anything yet that can shed light?
 > 
 > I've had *partial* success, by putting the socket into blocking mode and
 > sleeping for a bit prior to closing it (code excerpt enclosed at end).
 > However, this only cuts incidences of the problem by about 60%. Still
 > happens when writing larger amounts of data.
 > 
 > I also tried a lingering close() (again see code excerpt), but this seems to
 > have no effect.
 > 
 > I must admit that, despite being a C/Unix programmer in the past, I am very
 > new to the CYGWIN environment.
 > 
 > Somebody, please help.
 > 
 > David McNab
 > david AT rebirthing DOT co DOT nz
 > 
 > CODE EXCERPT FOLLOWS:
 > 
 > #ifndef HACK
 >  /* flush out the client socket - set it to blocking, then write to it */
 >  client_sock_flags=fcntl(client,F_GETFL,0);
 >     if(client_sock_flags!=-1)
 >     {
 >         PrintMessage(Important,"Trying to flush socket to client before
 > closing it");
 > 
 >         /* disable blocking */
 >   fcntl(client,F_SETFL,client_sock_flags ^ O_NONBLOCK);
 > 
 >   /* sent it a byte now that calls are blocking */
 >   write(client, &endchar, 1);
 > 
 >   /* hang about for a bit */
 >   sleep(5);
 >     }
 > #endif
 > 
 > #ifndef TRY_A_LINGERING_CLOSE
 >  /* this was suggested by CYGWIN people, but doesn't seem to do anything */
 >  {
 >   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); /* a small wrapper for 'close(client)' */
 > 
 > 
 > 

-- 
Markus Hoenicka, PhD
UT Houston Medical School
Dept. of Integrative Biology and Pharmacology
6431 Fannin MSB4.114
Houston, TX 77030
(713) 500-6313, -7477
(713) 500-7444 (fax)
Markus DOT Hoenicka AT uth DOT tmc DOT edu
http://ourworld.compuserve.com/homepages/hoenicka_markus/


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