Re: Sockets problem

On Mon, 22 Apr 2002 Ron@cpumms.com wrote:
>
> We are in the process of writing a new sockets program to talk to a new
> vendor., The vendor is the server and we are the client. We connect to them
> OK and then send our information. This is where the problem occurs. They
> hand off the connection to another socket and they still see us connected
> to the first socket, so they don't get the information we send.

Usually, the server program will accept() the connection from the client,
and then will create a new job/process to handle that connection.   This
process is entirely transparent to the client, the client never knows
that it happens.

However, there are exceptions to this.   Each application-level protocol
has it's own rules.   For example, FTP creates a new connection for each
file that you transfer.   It uses the first connection to negotiate which
address/port to use for a new connection to transfer each file.

This type of thing is the exception rather than the rule, however.

> Is there any coding we have to do to handle the new connection?
> I thought it was done "automagically" but I'm beginning to think not.

You use the term "new connection".  I may be reading too much into the
word "connection"...  but if there is more than one connection involved,
yes, you need to call connect() for each connection. :)

The way a server works is that you have one socket that simply listens for
new connections.   For each client that connects, the server calls
accept() which creates a new socket to handle that connection.   So, for
each instance of a client, you generally have only that one connection --
the one returned by the accept() API.

Then, the server will frequently pass that client off to a new process.
Normally on an AS/400 you'd use the givedescriptor() / takedescriptor()
APIs to pass the client to the new job.   Or, you might use spawn() to
pass it.  In either case, it's still just one connection.
So, that's how it USUALLY works.

However, your vendor may be doing something different.  Since I don't know
what application-level protocol he's using, I have no way of telling you
whether or not you need to do something special in this instance.
(presumably, it's something that he/she/they designed, and not an internet
standard that I could just look up)   So, you'll probably have to ask for
more information from the vendor.