bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bugs #11055] DO do not work on Windows 2003 Server


From: Willem Rein Oudshoorn
Subject: [bugs #11055] DO do not work on Windows 2003 Server
Date: Fri, 19 Nov 2004 07:50:30 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040817

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #11055] Latest Modifications:

Changes by: 
                Willem Rein Oudshoorn <woudshoo@xs4all.nl>
'Date: 
                Fri 11/19/2004 at 12:44 (Europe/Amsterdam)

------------------ Additional Follow-up Comments ----------------------------
Sorry, haven't figured out how to attach multiple files
in one go.






/**************************************************************************/
[bugs #11055] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11055>
Project: GNUstep
Submitted by: Willem Rein Oudshoorn
On: Fri 11/19/2004 at 12:43

Category:  Base/Foundation
Severity:  7 - Major
Item Group:  Bug
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open


Summary:  DO do not work on Windows 2003 Server

Original Submission:  Under windows 2003 server it distributed objects do not 
work.
The reason is that apparently the winsock semantics have 
changed slightly.

The following happens.
1 - Application registers connection with gdomap
2 - Another application inquires about the connection
3 - gdomap checks if the connection is still alive
    by trying to bind a socket on the same address
    as the original connection.  

    Now it used to be that this fails, (so
    gdomap knows the connection is still valid)
    but on windows 2003 server the binding succeed,
    so gdomap thinks the connection is gone and
    will remove the connection from its connection map.

After looking at the gdomap code there was a curious
comment just above the aforementioned check.

  /* FIXME: This must not be INADDR_ANY on Win,
     otherwise the system will try to bind on any of
     the local addresses (including 127.0.0.1), which
     works. - bjoern */

     sa.sin_addr.s_addr = addr[0].s_addr;

After removing this MINGW specific hack everything seems
to work fine.   However I assume bjoern added
this for a reasion, so I very hesitant to apply this fix.

If anyone can shed some light on this, please go ahead.

Oh, the attached program gso2.c will demonstrate this 
behaviour.

1 - compile with:
     gcc -o gso2 gso2.c -lwsock32

2 - Run in one command prompt:
     gso2 localhost

3 - Run in another comamnd prompt:
     gso2 localhost

The second gso2 invocation will tell on windows2000
that it can not bind the socket, but on windows2003 server
it will bind to the socket. 

Also I attach the patch that removes the MINGW code 
and seems to fix the problem.

Wim Oudshoorn.

Wim Oudshoorn.


Follow-up Comments
------------------


-------------------------------------------------------
Date: Fri 11/19/2004 at 12:44       By: Willem Rein Oudshoorn <wim>
Sorry, haven't figured out how to attach multiple files
in one go.






File Attachments
-------------------

-------------------------------------------------------
Date: Fri 11/19/2004 at 12:44  Name: gso2.c  Size: 1.45KB   By: wim
file that demonstrates binding behaviour
http://savannah.gnu.org/bugs/download.php?item_id=11055&amp;item_file_id=1896

-------------------------------------------------------
Date: Fri 11/19/2004 at 12:43  Name: gdomap.patch  Size: 1.21KB   By: wim
Patch removing MINGW specific code
http://savannah.gnu.org/bugs/download.php?item_id=11055&amp;item_file_id=1895






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=11055>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/







reply via email to

[Prev in Thread] Current Thread [Next in Thread]