in reply to Re^2: IO::Socket::INET -- Jettero verses non-blocking in windows
in thread IO::Socket::INET -- jettero verses non-blocking in windows

What vec() does is construct a bit vector, in this case related to the fileno of the client socket. Every filehandle on the OS has an actual file number. Consider: 

print fileno(STDIN), $", fileno(STDOUT), $", fileno(STDERR);
__DATA__
0 1 2

[download]

So STDIN is fileno 0, etc. When you open a file or a socket a unique fileno that identifies it is stored by the OS in the file table. So what the first vec is doing is generating a bitmask in $bits1 that represents that. What 4 arg select does is return values for handles that can be READ, WRITTEN and HAVE ERRORS. It waits the specified time and then returns. It returns the data in a bitmap type format. We use vec again to see if the bit that corresponds to the filehandle we are interested in has been set in the returned value. (vec returns true if it is set, false if not).

I don't know what you mean about how you get the ip address of the source - it is there in the code and being printed?

cheers

tachyon

Replies are listed 'Best First'.
Re^4: IO::Socket::INET -- Jettero verses non-blocking in windows
by jettero (Monsignor) on Jul 30, 2004 at 15:57 UTC

    Your method really does work, so I'm closer. I just don't know how to find the sender IP. Thanks a lot BTW.

    But, what I was actually asking is about how to find the sender IP. Check out the recv() I posted above.

    UDP doesn't really connect, so the source IP on each packet can be different. recv() returns some packet header info from which I can get the ip addr of the sender.

    Sysread doesn't do that at all. And the worse part is, the perldoc page for select() tells me that mixing your vec/select call with recv() is stupid and I'll get burnt.

    So I'm not sure what to do ...

[reply]

      To get that info you need raw socket access. You can do it I suppose but you are getting into a fairly deep area. See this for some idea of how easy it isn't. You will note that even WinSock support for it is not a given. It depends on which flavour you are running.

      Probably the easiest workaround is to accept that the socket will block on win32. To get a non-blocking effect run two processes. The blocking UDP message acceptor process block waiting for data, as you have now. When it has something to say it says it. The other process listens effectively via a non blocking read. Ugly but it would work and is probably the easiest implementation.

      cheers

      tachyon

[reply]
        Wow, thanks.

        I think I'll be giving up shortly. This is way too hard for me.

        It's 4 lines of code in Teh Lunix. I wonder why it's so hard to do in windows. Here's hoping Wx::Socket does what I need.

        I had this application toally done and working great before I even knew there was a Wx::Socket. I elected to use Wx because it's portable... by my IO::Socket wasn't portable.

        Anyway,

        Thanks a ton for all your help. It was very interesting.

[reply]

In Section Seekers of Perl Wisdom