Confused about a basic TCP daytime server program

Confused about a basic TCP daytime server program

Post by Ryan » Fri, 03 Dec 2010 16:04:22



Hi all,
    I wrote a simple daytime server program,the code is below and i felt
puzzle about the output.(I'll give the output under the code)
#include "unp.h"
#include <time.h>

int main(int argc,char **argv){

        struct sockaddr_in servaddr,cliaddr;
        socklen_t len;
        char buf[BUFSIZ];
        int listenfd,connfd;
        time_t t;

        if((listenfd = socket(AF_INET,SOCK_STREAM,0)) <0 ){
                perror("socket");
                return -1;
        }

        bzero(&servaddr,sizeof(servaddr));
        servaddr.sin_family = AF_INET;
        servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
        servaddr.sin_port = htons(atoi(argv[1]));

        if(bind(listenfd,(SA *)&servaddr,sizeof(servaddr)) < 0){
                perror("bind");
                return -1;
        }

        if(listen(listenfd,LISTENQ) < 0){
                perror("listen");    
                return -1;
        }

        for(;;){
                if((connfd = accept(listenfd,(SA *)&cliaddr,&len)) < 0){
                        if(errno == EINTR) continue;
                        else return -1;
                }
                printf("%s\n",cliaddr.sin_family ==                   AF_INET?"AF_INET":"NOT AF_INET");
                fprintf(stderr,"connect from %s\nport on %d\n",\
                        inet_ntop(cliaddr.sin_family,&cliaddr.sin_addr,buf,sizeof(buf)),\
                        ntohs(cliaddr.sin_port));
                t = time(NULL);
                sprintf(buf,"%s",ctime(&t));
                write(connfd,buf,strlen(buf));
                close(connfd);
        }

Quote:}

I issued twice connects from the client with ./cli 127.0.0.1 9999 and
the output in the server is
$./ser 9999
NOT AF_INET
connect from (null)
port on 1032
AF_INET
connect from 127.0.0.1
port on 55578

I don't understand why there is a (null) IP address here,so i changed
the "inet_ntop" to
inet_ntop(AF_INET,&cliaddr.sin_addr,buf,sizeof(buf)),\
                        ntohs(cliaddr.sin_port));
the output became:
NOT AF_INET
connect from 128.155.150.0
port on 1032
AF_INET
connect from 127.0.0.1
port on 35763

I don't know where i get the address 128.155.150.0 and i'm sure i set
the AF_INET constant to the client's socket address structure.
Will anyone explain that?
Thanks ahead

Ryan

 
 
 

Confused about a basic TCP daytime server program

Post by Jan Kandzior » Fri, 03 Dec 2010 18:40:15


Ryan schrieb:
Quote:

> if((connfd = accept(listenfd,(SA *)&cliaddr,&len)) < 0){

You missed to initialize len to sizeof(cliaddr), so the structure contents
gets truncated on store.

Kind regards

        Jan

 
 
 

Confused about a basic TCP daytime server program

Post by Ryan » Fri, 03 Dec 2010 18:53:49



Quote:> Ryan schrieb:

>> if((connfd = accept(listenfd,(SA *)&cliaddr,&len))<  0){

> You missed to initialize len to sizeof(cliaddr), so the structure contents
> gets truncated on store.

> Kind regards

>          Jan

Thanks,I did missed it!
 
 
 

Confused about a basic TCP daytime server program

Post by David Schwart » Sun, 05 Dec 2010 08:19:26



Your main issue was already identified, but I wanted to point out
another issue:

Quote:> ? ? ? ? servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

This is incorrect. INADDR_ANY is already in network byte order.
Converting it is an error.

DS

 
 
 

Confused about a basic TCP daytime server program

Post by Lawrence D'Oliveir » Sun, 05 Dec 2010 10:50:36


In message



>> servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

> This is incorrect. INADDR_ANY is already in network byte order.
> Converting it is an error.

Yeah, but thats one of the addresses where it doesnt matter. :)
 
 
 

Confused about a basic TCP daytime server program

Post by David Schwart » Tue, 07 Dec 2010 08:17:40




> > This is incorrect. INADDR_ANY is already in network byte order.
> > Converting it is an error.
> Yeah, but thats one of the addresses where it doesnt matter. :)

Not on Linux it doesn't. On other platforms, who knows.

DS

 
 
 

Confused about a basic TCP daytime server program

Post by Richard Kettlewel » Tue, 07 Dec 2010 19:39:46




>>> This is incorrect. INADDR_ANY is already in network byte order.
>>> Converting it is an error.

>> Yeah, but thats one of the addresses where it doesnt matter. :)

> Not on Linux it doesn't. On other platforms, who knows.

It's still 0.  It's a property of TCP/IP, it's not chosen by each OS.

--
http://www.greenend.org.uk/rjk/

 
 
 

Confused about a basic TCP daytime server program

Post by Richard Kettlewel » Tue, 07 Dec 2010 19:57:38





>>>> This is incorrect. INADDR_ANY is already in network byte order.
>>>> Converting it is an error.

>>> Yeah, but thats one of the addresses where it doesnt matter. :)

>> Not on Linux it doesn't. On other platforms, who knows.

> It's still 0.  It's a property of TCP/IP, it's not chosen by each OS.

I would add: passing it to htonl() may be unnecessary but it is
certainly not an error to do so.  The majority of the INADDR_ constants
are in host order, are not palindromes, and therefore do need swapping.

Historically (at least one version of) syslogd used port 514 and
neglected to byte-swap it.  A mistake in the source, certainly, but not
a bug at runtime, for the same reason.

--
http://www.greenend.org.uk/rjk/

 
 
 

Confused about a basic TCP daytime server program

Post by David Schwart » Wed, 08 Dec 2010 09:10:06





> >>> This is incorrect. INADDR_ANY is already in network byte order.
> >>> Converting it is an error.

> >> Yeah, but thats one of the addresses where it doesnt matter. :)

> > Not on Linux it doesn't. On other platforms, who knows.

> It's still 0. ?It's a property of TCP/IP, it's not chosen by each OS.

INADDR_ANY is an API detail, not a property of TCP/IP. I know of no
rule that requires INADDR_ANY to be equivalent to zero. Nor do I know
of any rule that requires htonl(0) to be equivalent to zero.

DS

 
 
 

Confused about a basic TCP daytime server program

Post by David Schwart » Wed, 08 Dec 2010 09:16:36



Quote:> I would add: passing it to htonl() may be unnecessary but it is
> certainly not an error to do so.

It is an error to do so if you intend your code to be portable.

Quote:>?The majority of the INADDR_ constants
> are in host order, are not palindromes, and therefore do need swapping.

That may be so, but those are INNADR_ constants that are not defined
by POSIX.

Quote:> Historically (at least one version of) syslogd used port 514 and
> neglected to byte-swap it. ?A mistake in the source, certainly, but not
> a bug at runtime, for the same reason.

Nevertheless, portable (POSIX) code must use INADDDR_ANY as is. There
is no guarantee that htonl will do anything sensible to it. POSIX does
not anywhere specify what happens if you pass INADDR_ANY to htonl, the
resulting constant may or may not have any meaning to the API.

DS

 
 
 

Confused about a basic TCP daytime server program

Post by Rick Jone » Wed, 08 Dec 2010 08:42:21


Quote:> > It's still 0. ?It's a property of TCP/IP, it's not chosen by each
> > OS.
> INADDR_ANY is an API detail, not a property of TCP/IP. I know of no
> rule that requires INADDR_ANY to be equivalent to zero.

The layout of the IPv4 address space doesn't leave many options for it
other than zero though.  At least as a 32-bit quantity.

rick jones
Then again, if all the world were big-endian, the issue would be moot :)
--
It is not a question of half full or empty - the glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

 
 
 

Confused about a basic TCP daytime server program

Post by David Schwart » Wed, 08 Dec 2010 10:15:56



Quote:> > INADDR_ANY is an API detail, not a property of TCP/IP. I know of no
> > rule that requires INADDR_ANY to be equivalent to zero.
> The layout of the IPv4 address space doesn't leave many options for it
> other than zero though. ?At least as a 32-bit quantity.

True. I think it does have to be a 32-bit quantity. However, I don't
see any rule that htonl(0)==ntohl(0)==0 must be the case. (Though I
think we will probably never see a platform where that's not true.)

DS

 
 
 

Confused about a basic TCP daytime server program

Post by Richard Kettlewel » Wed, 08 Dec 2010 20:21:17






>>>>> This is incorrect. INADDR_ANY is already in network byte order.
>>>>> Converting it is an error.

>>>> Yeah, but thats one of the addresses where it doesnt matter. :)

>>> Not on Linux it doesn't. On other platforms, who knows.

>> It's still 0. ?It's a property of TCP/IP, it's not chosen by each OS.

> INADDR_ANY is an API detail, not a property of TCP/IP. I know of no
> rule that requires INADDR_ANY to be equivalent to zero.

Have a look at the IANA assigned numbers pages (or the RFC they
replaced, which also has 0=this host).

Also, have a look at ancient BSD sources, which do indeed pass
INADDR_ANY through htonl() (e.g. via inet_makeaddr).

Or, you know, define it to be 209.86.229.100 on your private operating
system.  But don't expect it to work very well.

Quote:> Nor do I know of any rule that requires htonl(0) to be equivalent to
> zero.

Byte swapping 0 can only yield 0.

For that matter there's nothing in SUS/POSIX telling you which byte
order INADDR_ANY and INADDR_BROADCAST are in.  But the reason is
obvious: they are both palindromes.

--
http://www.greenend.org.uk/rjk/

 
 
 

Confused about a basic TCP daytime server program

Post by Lawrence D'Oliveir » Thu, 09 Dec 2010 07:32:13


In message





>> >>> This is incorrect. INADDR_ANY is already in network byte order.
>> >>> Converting it is an error.

>> >> Yeah, but thats one of the addresses where it doesnt matter. :)

>> > Not on Linux it doesn't. On other platforms, who knows.

>> It's still 0.  It's a property of TCP/IP, it's not chosen by each OS.

> INADDR_ANY is an API detail, not a property of TCP/IP. I know of no
> rule that requires INADDR_ANY to be equivalent to zero.

But any other value would conflict with a valid IP address.
 
 
 

Confused about a basic TCP daytime server program

Post by Lawrence D'Oliveir » Thu, 09 Dec 2010 07:34:27



Quote:> Then again, if all the world were big-endian, the issue would be moot :)

But even on big-endian architectures, registers tend to be little-endian
<http://wlug.org.nz/BigEndian>.