this client test program fails to connect to the server test program

[kaoutsis]

hrev24888

• on qemu, client: connect failed: Connection refused

[kaoutsis]

on real hardware (hrev24888), connect() doesn't return

[axeld]

You're using something like this several times: struct sockaddr_in server_addr = {AF_INET, htons(serverPort)};

But this is wrong - the first member is sin_len, not sin_family. The code you probably copied that from is broken :-) BTW there is already a similar test app, called tcp_server.cpp, and tcp_client.cpp.

[kaoutsis]

Replying to axeld:

You're using something like this several times: struct sockaddr_in server_addr = {AF_INET, htons(serverPort)};

But this is wrong - the first member is sin_len, not sin_family. The code you probably copied that from is broken :-)

or historic? :-) ​http://www.fortunecity.com/skyscraper/arpanet/6/cc.htm i made the corrections, and now the program runs fine on haiku, thanks! But i still can't find why linux had no complains with the historic implementation. (Before the corrections, linux had no problem; even then the connection was fine)

BTW there is already a similar test app, called tcp_server.cpp, and tcp_client.cpp.

Yes. That was my first network program; i wanted to try something different :-)

[axeld]

The problem with using the {...} initialization is that it makes assumptions on how the sockaddr structure (or sockaddr_in) looks like. The result is that it may or may not work on a platform - it's like Russian roulette. The actual members and the order of the sockaddr fields is unspecified.

[kaoutsis]

Replying to axeld:

The problem with using the {...} initialization is that it makes assumptions on how the sockaddr structure (or sockaddr_in) looks like. The result is that it may or may not work on a platform - it's like Russian roulette. The actual members and the order of the sockaddr fields is unspecified.

You are right. I'll keep that in mind, thanks.