|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.