[LCP]sockets problem

[Paul Gearon]

On Wed, 30 Jan 2002, [iso-8859-1] Srinath © wrote:

> > > #define CLIENTPORT 4999
> > It's rather unusual to define the local port number.  You normally allow
> >the  local port to be allocated automatically (though it won't hurt to do
> this).
>
> In my program, the client also listens for connections. so when i bind a
> 'listen' socket in client to some port (that is not known to server), then
> how
> will the server know which port to connect to in the client. In other words,
> how do i do this - the server wants to send a  message to the client. how
> does it fill the  : clientsockaddr_in.sin_port ?

This was because I looked at your code late at night and made a mistake.
:-)  When I saw "CLIENTPORT" I incorrectly assumed you were binding the
port number at the client side (which is possible, but rarely necessary).
Sorry about that.  :-)

However, as others have mentioned, a client using TCP will rarely need to
listen on a port (active FTP being one notable exception).  TCP
connections are bidirectional and persistent, so the design should be more
like the following:

1. Server sets up a listening socket and waits for a connection

2. Client connects to the server

3a. Client waits for data on stdin or socket
3b. Server waits for data on stdin or socket

4a. If client gets data on stdin then write to socket, data from socket
goes to stdout.
4b. If server gets data on stdin then write to socket, data from socket
goes to stdout.

5a. If client sees EOF from either file descriptor then close connection
and exit.
5b. If server sees EOF from stdin then close connection and exit.  If it
sees EOF on the socket then close the socket and go back to step 1.


This is quite rudimentary, particularly as it doesn't permit multiple
clients to connect to the server, but it should give you an idea of how
this program should have been structured.

> i referred the man pages and it is not clear ; according to my 'wrong
> source' what will happen :
> 1) the set file descriptor in the clientset will always remain set (or)
> 2) the set file descriptor in the clientset will be the only one tested
> after that ??

Frankly, I wasn't entirely clear on this since I usually use the FD_
without giving it much thought.  I've looked it up so I can be clearer.
:-)

The file descriptor set is a bitmask which is 1024 bits long (stored as an
array of integers, but you shouldn't need to know that).  FD_ZERO sets all
of the bits in the mask to "0".  FD_SET will set a single bit in this
bitmask to "1".  FD_ISSET tests if a particular bit is set to "1".  When
you pass this bitmask to select() it checks all the file descriptors which
correspond to the bits which are set to "1".

Once it detects the desired activity on one of these file descriptors,
select() will set ALL OTHER file descriptor bits to "0" and return.  So
the file descriptors which have activity don't actually need their bits to
be reset, but any file descriptors without activity will need to set their
bits again.

Now back to your original code.  You never reset the bits before calling
select.  If you receive socket activity, then you the bit for stdin goes
to "0".  Thereafter select() will only be looking for the socket file
descriptor.  The same goes for stdin - once you get data on stdin you'll
never detect data on the socket.

> >     if(FD_ISSET(0,&masterset))
> >     {
> >      /* CONTROL IS NEVER COMING HERE AS NOTHING IS PRINTED */
> >       printf("keyboard getting ctrl");

If you've received socket IO in the server (which you will as soon as the
client connects) then control will never pass to this section.  Sorry I
didn't notice this earlier, but I fixed the FD_SET problems first, so I
didn't see this problem.  :-)

> > Actually, control *is* being passed here, but nothing gets printed until
> >he  buffer for stdout gets flushed.  :-)  When I got this working the
> program
> >an  fine, and when I exited I had a line full of "keyboard getting ctrl"
> >lushed to  stdout.
>
> should i fflush(stdout) anywhere here?

If you really need it, then yes.  However once you get the code working
you may find you don't need to.

Regards,
Paul Gearon

Software Engineer                Telephone:   +61 7 3876 2188
Plugged In Software              Fax:         +61 7 3876 4899
http://www.PIsoftware.com        PGP Key available via finger

Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam.
(Translation from latin: "I have a catapult. Give me all the money,
or I will fling an enormous rock at your head.")