Confused about a basic TCP daytime server program

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);
}
}

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

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

On 2010年12月02日 17:40, Jan Kandziora wrote:
> 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!

In message
<a204bfc7-0b3b-45af-9440-(E-Mail Removed)>, David
Schwartz wrote:

> On Dec 1, 11:04 pm, Ryan <eric...@gmail.com> wrote:
>
>> 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 that’s one of the addresses where it doesn’t matter.

David Schwartz <(E-Mail Removed)> writes:
> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:

>>> This is incorrect. INADDR_ANY is already in network byte order.
>>> Converting it is an error.
>>
>> Yeah, but that’s one of the addresses where it doesn’t 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/

Richard Kettlewell <(E-Mail Removed)> writes:

> David Schwartz <(E-Mail Removed)> writes:
>> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>
>>>> This is incorrect. INADDR_ANY is already in network byte order.
>>>> Converting it is an error.
>>>
>>> Yeah, but that’s one of the addresses where it doesn’t 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/

> > 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...

David Schwartz <(E-Mail Removed)> writes:
> Richard Kettlewell <r...@greenend.org.uk> wrote:
>> David Schwartz <dav...@webmaster.com> writes:
>>> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:

>>>>> This is incorrect. INADDR_ANY is already in network byte order.
>>>>> Converting it is an error.
>>>>
>>>> Yeah, but that’s one of the addresses where it doesn’t 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.

> 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/

In message
<09588d1c-7d88-46ca-bf27-(E-Mail Removed)>, David
Schwartz wrote:

> On Dec 6, 2:39 am, Richard Kettlewell <r...@greenend.org.uk> wrote:
>> David Schwartz <dav...@webmaster.com> writes:
>
>> > Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>> >>> This is incorrect. INADDR_ANY is already in network byte order.
>> >>> Converting it is an error.
>>
>> >> Yeah, but that’s one of the addresses where it doesn’t 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.

In message <idjsct$9f9$(E-Mail Removed)>, Rick Jones wrote:

> 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>.