[LCP]sockets problem

[Andrew Weaver]

> -----Original Message-----
> From:	Srinath © [SMTP:redindian at nettaxi.com]
> Sent:	Wednesday, January 30, 2002 1:31 AM
> To:	linuxcprogramming at lists.linux.org.au
> Subject:	Re: [LCP]sockets problem
> 
> Hello all,
> The program now works fine. Thanks for all your emails .
> I have some more doubts. Thanks for spending your time in this.
> 
> 
> > > #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 ?
> 
[Andy]  Well yes but as someone else pointed out, normally you establish the
server and the clients connect to it an maintain the connection until they
are done. So, the real issue is how to export the server port? See
getservbyname() and friends. Export the name into the environment and make
sure it is resolved via NIS or /etc/services.

> > OK, here's your first big problem.  You're setting up "clientset"
> outside
> >of your loop.  That only works the first time through.  After select()
> returns,
> >clientset  has one of the file descriptors set (which you correctly check
> with
> > FD_ISSET) but  it *stays* set the next time through the loop.  That
> means
> that clientset
> > is not set correctly the next time you call select().
> 
> 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 ??
> 
[Andy]  OK. The return from select() is zero for nothing got hit, -1 for
some problem (see errno = EINTR) or > 0 meaning "n" descriptors from your
sets have been hit. The specific hits are recorded in the sets that you gave
to select() (hence they are &set). If you want the full range of possibles
to be tested next time through the select(), you have to reset the set.

> >     if(FD_ISSET(0,&masterset))
> >     {
> >      /* CONTROL IS NEVER COMING HERE AS NOTHING IS PRINTED */
> >       printf("keyboard getting ctrl");
> >
> > 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?
> 
[Andy]  Well, stdout is buffered and, yes, there can be some delay in seeing
the stuff out through there but... You could fflush(stdout) immediately
after the printf or fprintf(stdout);

> Srinath
> 
> 
> _______________________________________________
> This is the Linux C Programming List
> :  http://lists.linux.org.au/listinfo/linuxcprogramming List