Re: Sockets server problem

[Scott Klement <klemscot@xxxxxxxxxxxx>]

>         I set the socket descriptor (using socket 9700),  set the socket to
> be reusable, bind socket (9700), and Listen.

I sure hope you mean port 9700, rather than socket 9700!  You don't really
have 9701 sockets open, do you?

> When the client transmits data to 9700, my program begins a loop to
> accept and will set up a secondary socket while it receives the data and
> does what it wants with it.

What do you mean by "secondary" socket?  Are you talking about the
descriptor to the connected client that's returned by accept()?

> Then, when I've finished working with the data, I send an ACK message
> back on the secondary socket and close that socket leaving 9700 still
> open for another request.  The client says that this shuts their
> connection to 9700 down.

Correct...  That's what close() does, it shuts the connection down.
Is that what you wanted to do?   If not, what did you want to do?

>       At their request, I left each secondary socket open and when they
> tried to send a second message during testing, I watched it try to come
> over on the first secondary socket.  Then, after awhile, a new secondary
> socket was set and the data transmitted on that new secondary socket and I
> sent an ACK on that socket.

Maybe it's because I don't know what a "secondary socket" is, but I'm
having a really hard time trying to figure out what this paragraph says.

> This, of course, is unacceptable as I would have all these open
> secondary sockets sitting there.  I was told that their program is
> attempting to find the open socket (which I've closed) and is going thru
> several sockets looking for an open one.  Is this right?  Or am I doing
> something wrong from my end?

Can you tell us how the application is supposed to work?

Normally, I would expect that a client would connect to port 9700.  A
server process would handle requests from that client until the client
either told the server to stop, or the client disconnected.

But, that's certainly not the only way to do it.  The rexec/rcmd protocol,
and the FTP protocol are examples of protocols that work completely
differently from that "normal" way.

Really, the first step is to define clearly how you want your application
protocol to work.  What data is sent to issue a command from the client to
the server?  What kinds of responses should the client expect back?  How
are errors handled?  When does the connection terminate?   These are all
things that should be addressed in your definition of the application
protocol.

Hope that helps...