I am writing a simulator that talks to an existing server.  This server
accepts multiple (12) connections, in the real world from PCs that are
transfering messages from hardware devices.

If I connect to the server locally, that is, my client running on the same
box, it's fine and I can run multiple instances .. as long as I'm using the
loopback address (127.0.0.1).  If I utilize the real IP address, the 2nd
connect works, but breaks the first connection with a -1 ECONNRESET (or
whatever, not handy right now).  Doesn't matter if I'm on the same host or
not when I specify the server's IP.  Only the last session persist.

I'm able to connect from multiple hosts but the previous connection is
always reset once the second connection is made.

Am I missing something fundamental here?

TIA

[ Post a follow-up to this message ]

R Smith wrote:

> I am writing a simulator that talks to an existing server.  This server
> accepts multiple (12) connections, in the real world from PCs that are
> transfering messages from hardware devices.
>
> If I connect to the server locally, that is, my client running on the same
> box, it's fine and I can run multiple instances .. as long as I'm using th
e
> loopback address (127.0.0.1).  If I utilize the real IP address, the 2nd
> connect works, but breaks the first connection with a -1 ECONNRESET (or
> whatever, not handy right now).  Doesn't matter if I'm on the same host or
> not when I specify the server's IP.  Only the last session persist.
>
> I'm able to connect from multiple hosts but the previous connection is
> always reset once the second connection is made.
>
> Am I missing something fundamental here?

TCP socket? UDP socket? Raw socket? UNIX socket?

You would need to provide a small example demonstrating your problem.

[ Post a follow-up to this message ]

Here are the client snippets that matter.  This using the loopback for
the time being.  Reading and writing is fine.  It's just until the 2nd
instance comes along.  The server has been working for years.  It
listens and accepts connections, then forks off a process to handle the
incoming connection.

>     bzero((char *) &serv_addr, sizeof(serv_addr));
>     serv_addr.sin_family       = AF_INET;
>     serv_addr.sin_addr.s_addr  = inet_addr("127.0.0.1");
>     serv_addr.sin_port         = htons(LANE_SERVER_TCP_PORT);
>
> /*
>  * Open a TCP socket (an Internet stream socket)
>  */
>
>     if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
>     {
>         fprintf(stderr,"Lane Client: can't open stream socket errno =
%d\n", errno);
>         exit(1);
>     }
>     one = 1;
>     if (setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (char *)&one,
sizeof(one)) < 0)
>         err_sys("SO_KEEPALIVE setsockopt error");
>     linger.l_onoff  = 1;
>     linger.l_linger = 0;
>     if (setsockopt(sockfd, SOL_SOCKET, SO_LINGER, (char *)&linger,
sizeof(linger)) < 0)
>         err_sys("SO_LINGER setsockopt error");



/*
* Connect to the Server
*/

if (connect (sockfd, (struct sockaddr *) &serv_addr, sizeof
(serv_addr)) < 0)
{
fprintf(stderr, "Lane client, Connect call failed errno = %d\n",
errno);
exit(1);
}

FD_ZERO(&writemask);
FD_ZERO(&readmask);
FD_SET(sockfd, &readmask);
FD_SET(sockfd, &writemask);
if (select(sockfd + 1, (fd_set *)&readmask, (fd_set *)
&writemask,
(fd_set *)0, &timeout) < 0)
{
err_sys("Select error");
}
if (FD_ISSET(sockfd, &readmask))
{
rv = read_msg (sockfd);
if (rv < 0)
{
return(-1);
}
}

[ Post a follow-up to this message ]

Ha! Sorry about that.  Had some old settings in my xnews reader that I
overlooked so it posted as someone else.

Derek Wayne <wayne.derek@gmail.com> wrote in
 news:Xns98BC41806D085waynederekgmailcom@
216.196.97.131:

> Here are the client snippets that matter.  This using the loopback for
> the time being.  Reading and writing is fine.  It's just until the 2nd
> instance comes along.  The server has been working for years.  It
> listens and accepts connections, then forks off a process to handle
the
> incoming connection.
> 
> %d\n", errno); 
> sizeof(one)) < 0) 
> sizeof(linger)) < 0) 
>
>
>
> /*
>  * Connect to the Server
>  */
>
>     if (connect (sockfd, (struct sockaddr *) &serv_addr, sizeof
> (serv_addr)) < 0)
>     {
>         fprintf(stderr, "Lane client, Connect call failed errno = %d
\n",
> errno);
>         exit(1);
>     }
>
>         FD_ZERO(&writemask);
>         FD_ZERO(&readmask);
>         FD_SET(sockfd, &readmask);
>         FD_SET(sockfd, &writemask);
>         if (select(sockfd + 1, (fd_set *)&readmask, (fd_set *)
> &writemask,
>            (fd_set *)0, &timeout) < 0)
>         {
>             err_sys("Select error");
>         }
>         if (FD_ISSET(sockfd, &readmask))
>         {
>             rv = read_msg (sockfd);
>             if (rv < 0)
>             {
>                 return(-1);
>             }
>         }
>

[ Post a follow-up to this message ]

R Smith wrote:
> I am writing a simulator that talks to an existing server.  This server
> accepts multiple (12) connections, in the real world from PCs that are
> transfering messages from hardware devices.
>
> If I connect to the server locally, that is, my client running on the same
> box, it's fine and I can run multiple instances .. as long as I'm using th
e
> loopback address (127.0.0.1).  If I utilize the real IP address, the 2nd
> connect works, but breaks the first connection with a -1 ECONNRESET (or
> whatever, not handy right now).  Doesn't matter if I'm on the same host or
> not when I specify the server's IP.  Only the last session persist.
>
> I'm able to connect from multiple hosts but the previous connection is
> always reset once the second connection is made.
>
> Am I missing something fundamental here?
Sounds like you somehow close the prior session when a new one
is established.
It's hard to give any more advice with the information provided.
Show e.g. some relevant code.

[ Post a follow-up to this message ]

I did (above) under an old name stuck in my news reader.  Like I said
the server has been working for years accepting connections from
multiple hosts and processing the transactions.

I think there is some relevance in that with the loopback address,
multiple local connections are fine but with the specific IP (on the
same machine) I can only keep the last connection going.

"Nils O. Selåsdal" <NOS@Utel.no> wrote in
news:45af62e8$1@news.broadpark.no:

> R Smith wrote: 
> Sounds like you somehow close the prior session when a new one
> is established.
> It's hard to give any more advice with the information provided.
> Show e.g. some relevant code.
>

[ Post a follow-up to this message ]

In article <Xns98BC3C0B7A772waynederekgmailcom@216.196.97.131>,
R Smith <rhsmith52@comcast.net> wrote:

> I am writing a simulator that talks to an existing server.  This server
> accepts multiple (12) connections, in the real world from PCs that are
> transfering messages from hardware devices.
>
> If I connect to the server locally, that is, my client running on the same
> box, it's fine and I can run multiple instances .. as long as I'm using th
e
> loopback address (127.0.0.1).  If I utilize the real IP address, the 2nd
> connect works, but breaks the first connection with a -1 ECONNRESET (or
> whatever, not handy right now).  Doesn't matter if I'm on the same host or
> not when I specify the server's IP.  Only the last session persist.
>
> I'm able to connect from multiple hosts but the previous connection is
> always reset once the second connection is made.
>
> Am I missing something fundamental here?

Can you post a tcpdump showing the connections on this port?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

My bad all along.  My code was properly written after all.  I finally
looked at the server code and realized that, long ago, logic was added to
insure that only one connection per client IP was allowed ... unless using
the loopback address (for testing).  It just didn't occur to me until
yesterday.

My apologies for crying wolf.

[ Post a follow-up to this message ]