Hi,

I am trying to port my Ping module from window to linux, and I've
encountered some odd, but interesting things.

I have a function to keep creating new sockets.

bool PingIt(unsigned long targetip)
{
// Create Variables
struct sockaddr_in target;
int newSocket = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);

// Setup destination socket address
target.sin_addr.s_addr = inet_addr(szIP);
target.sin_family = AF_INET;
target.sin_port = 0;

// Send Echo
SendEcho(newSocket, &target);

// Use select() to wait for data to be received
// 		default timeout value = 2 sec
return(WaitForEchoReply(newSocket, timeout));
}

this guy works fine on window, but when it comes it linux, everytime
when the program calls PingIt(), the *newSocket* will remain the same
value. Unlike windows, it changes eveytime. That gives the program a
brand new socket. Do you guys know why?

This is interesting. Thanks for helping.

Best wishes,

- eric

[ Post a follow-up to this message ]

In article <4b2febc7.0409172202.3c57c3a8@posting.google.com>,
tikviva@yahoo.com (tikviva) wrote:

> Hi,
>
> I am trying to port my Ping module from window to linux, and I've
> encountered some odd, but interesting things.
>
> I have a function to keep creating new sockets.
>
...
>
> this guy works fine on window, but when it comes it linux, everytime
> when the program calls PingIt(), the *newSocket* will remain the same
> value. Unlike windows, it changes eveytime. That gives the program a
> brand new socket. Do you guys know why?

This is hardly a complete example -- what does WaitForEchoReply() do?
Does it close the socket?  Also, the above text might be read to
indicate something is going wrong -- does the program not work, or are
you just confused by the fact that newSocket is always the same number?

On UNIX, a socket is represented by a slot in the file descriptor table.
Any new socket (or file, etc.) gets the lowest available descriptor
number.  So if WaitForEchoReply() closes newSocket, then you'll always
get the same number back, assuming nothing else in your program is
opening files.

I'm not very familiar with windows, but it probably uses some different
scheme.  (the Unix scheme is as it is for historical reasons, mostly)

To look at the file descriptors your program has in detail, you can do:

ls -l /proc/pid/fd

where "pid" is the process ID of your program (retrievable in the
program using getpid(2)).

Cheers,
- jonathan

[ Post a follow-up to this message ]

Thanks Jonathan,

I know what I did wrong in the implementation though, I've put *1* in
the first parameter of the select() function.

As I've passed a socket in FD_SET(socketnum, &readfds)
so, when program calls the select(), the first parameter should be
*socketnum + 1*, which is totally different in the Win32
implementation, it requires me to put a *1* instead.

that's interesting. don't you think? even though I've been looking at
this for 2 days. yea.. a long time. =)

Anyway, thanks though.

Jonathan Adams <jwadams@gmail.com> wrote in message news:<jwadams-426FA1.02110318092004@news
1nwk.sfbay.sun.com>...
> In article <4b2febc7.0409172202.3c57c3a8@posting.google.com>,
>  tikviva@yahoo.com (tikviva) wrote:
> 
>  ... 
>
> This is hardly a complete example -- what does WaitForEchoReply() do?
> Does it close the socket?  Also, the above text might be read to
> indicate something is going wrong -- does the program not work, or are
> you just confused by the fact that newSocket is always the same number?
>
> On UNIX, a socket is represented by a slot in the file descriptor table.
> Any new socket (or file, etc.) gets the lowest available descriptor
> number.  So if WaitForEchoReply() closes newSocket, then you'll always
> get the same number back, assuming nothing else in your program is
> opening files.
>
> I'm not very familiar with windows, but it probably uses some different
> scheme.  (the Unix scheme is as it is for historical reasons, mostly)
>
> To look at the file descriptors your program has in detail, you can do:
>
>     ls -l /proc/pid/fd
>
> where "pid" is the process ID of your program (retrievable in the
> program using getpid(2)).
>
> Cheers,
> - jonathan

[ Post a follow-up to this message ]