Problem with connct() routine

Problem with connct() routine

Post by Tan Hung Khoo » Fri, 13 Sep 1996 04:00:00



I am encountering some strange problems with the connect() routine on
IBM RS/6000 running AIX 3.2.

Before calling connect(), my program (client) calls bind() to bind the
socket to a specified port number and local host.  The program will
connect to another specified port number on which another program
(server) is listening.  What I need is the listening program will call
accept() and extract the port number bound to the connecting socket.

When I terminate the client while the server is still running, and then
restart the client, the connect() routine returns an EADDRINUSE error.
The funny thing is that bind() returns no error (I set the socket option
for SO_REUSEADDR).  However, after a number of EADDRINUSE error, the
connect() routine will eventually be successful.  On RS/6000, I have
tested that if the client is restarted 55 seconds after termination,
connect() is always successful.  But is I restart the client at 50
seconds after termination, I will get EADDRINUSE at the connect()
routine.

Has anyone encountered the same problem or experienced similar situation
before?  Would like to know what is the cause to this problem and how to
go about solving it.  I suspect some kind of daemon for the network card
running at pre-defined time interval in releasing network resources
(ie., port numbers) maybe the reason but is not certain.

Thanks in advance to any reply.

 
 
 

Problem with connct() routine

Post by Andrew Gier » Tue, 17 Sep 1996 04:00:00


 Tan> I am encountering some strange problems with the connect()
 Tan> routine on IBM RS/6000 running AIX 3.2.

 Tan> Before calling connect(), my program (client) calls bind() to
 Tan> bind the socket to a specified port number and local host.  The
 Tan> program will connect to another specified port number on which
 Tan> another program (server) is listening.  What I need is the
 Tan> listening program will call accept() and extract the port number
 Tan> bound to the connecting socket.

Calling bind() before connect() has all sorts of pitfalls, one of which
has bitten you. There are very, very few cases where a client program
should be using a fixed port number. See the socket FAQ for a fuller
explanation.

 Tan> When I terminate the client while the server is still running,
 Tan> and then restart the client, the connect() routine returns an
 Tan> EADDRINUSE error.  The funny thing is that bind() returns no
 Tan> error (I set the socket option for SO_REUSEADDR).  However,
 Tan> after a number of EADDRINUSE error, the connect() routine will
 Tan> eventually be successful.  On RS/6000, I have tested that if the
 Tan> client is restarted 55 seconds after termination, connect() is
 Tan> always successful.  But is I restart the client at 50 seconds
 Tan> after termination, I will get EADDRINUSE at the connect()
 Tan> routine.

What's happening here is that the original connection remains in TIME_WAIT
state for a time after being closed. Since the 5-tuple (protocol, local
address, local port, remote address, remote port) must be unique at all
times, the attempt to establish a connection between the same ports fails.
Solution: don't use a fixed port number for the client - let the system
pick one for you.

 Tan> Has anyone encountered the same problem or experienced similar
 Tan> situation before?  Would like to know what is the cause to this
 Tan> problem and how to go about solving it.  I suspect some kind of
 Tan> daemon for the network card running at pre-defined time interval
 Tan> in releasing network resources (ie., port numbers) maybe the
 Tan> reason but is not certain.

 Tan> Thanks in advance to any reply.

The unix-socket-faq is regularly posted here and in comp.answers, and may
also be found at:

  http://www.auroraonline.com/sock-faq
  http://kipper.york.ac.uk/~vic/sock-faq
  ftp://rtfm.mit.edu/pub/usenet/news.answers/unix-faq/socket

Hope this helps

--

"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam

 
 
 

1. Problem With my Read routine

Hi:

I am writing a device driver for a pci card for SOLARIS2.6 running on an
ULTRA 30 machine.

I am implementing the driver as a character STREAMS driver.

This is my decleration for the streamtab structure(9S)

struct streamtab pci9050StreamTabInfo = {

    &pciQInit,            /*    Read qinit(9S) structure    */
    &pciWQInit,          /*    Write qinit(9s) structure    */
    NULL,
    NULL

Here is the decleration for my read side qinit(9S) structure -

/*
 *   Read Queue.
 */

static struct qinit pci9050RQInit  = {
        pci9050ReadPut,
        pci9050ReadService,
        pci9050Open,
        pci9050Close,
        NULL,
        &pci9050ModuleInfo,
        NULL
        };

The write qinit structure is the same as this one except for its own
read and service routines and it has no open or close routines either.

I am able to add the driver to the system. However the read routines are
not being  called. I am able to call the write routines without a
problem and they work fine.

Can anyone tell me why my read procedures are not being called and only
my write procedures are being called.

Things that I have done to figure this out.

a)    Checked if appropriate permissions are given for the device.
b)    Made sure that I havent made a typo (Wouldnt copile if I had)
c)    Tried to move the open and close routines to my write qinit
structure -- No difference.

Any suggestions are welcome. Can you recommend a good debugger to tell
me exactly where I have screwed up.


Yours Sincerely,

Chinmay V. P.
University Of South Florida.

2. loading graphic card LUTs

3. Problem accessing routine in libc.a from C++

4. The next Linus Torvalds?

5. BIG PROBLEM WITH "fopen" C ROUTINE!!!

6. Raid performance Promise SX6000 / kernel 2.4.18 i2o

7. Problems with ndbm database routines

8. Hard disk info resource

9. "Make" rookie has GCC problem while running configure/make routine

10. PROBLEM: NTFS routine fs/ntfs/unistr.c does not compile

11. Linux 2.4 kernel routines problem

12. [Fwd: Problem With my Read routine]

13. problem in driver read routine