public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* CYGWIN Socket write() problem in 1.1.7 DLL
@ 2001-01-04 16:06 David McNab
  2001-01-04 16:26 ` Markus Hoenicka
  0 siblings, 1 reply; 2+ messages in thread
From: David McNab @ 2001-01-04 16:06 UTC (permalink / raw)
  To: Markus.Hoenicka, cygwin

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@rebirthing.co.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)' */




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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* CYGWIN Socket write() problem in 1.1.7 DLL
  2001-01-04 16:06 CYGWIN Socket write() problem in 1.1.7 DLL David McNab
@ 2001-01-04 16:26 ` Markus Hoenicka
  0 siblings, 0 replies; 2+ messages in thread
From: Markus Hoenicka @ 2001-01-04 16:26 UTC (permalink / raw)
  To: cygwin

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@rebirthing.co.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.Hoenicka@uth.tmc.edu
http://ourworld.compuserve.com/homepages/hoenicka_markus/


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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-01-04 16:26 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-01-04 16:06 CYGWIN Socket write() problem in 1.1.7 DLL David McNab
2001-01-04 16:26 ` Markus Hoenicka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).