Version française
Home     About     Download     Resources     Contact us    
Browse thread
UDP broadcast from Windows
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] UDP broadcast from Windows
Reed Wilson wrote:
> Hi guys!
>
> I'm in the middle of writing a program which does a UDP broadcast, but I
> noticed it doesn't work on Windows. Here's the source:
>
> try (
>   let sock = Unix.socket Unix.PF_INET Unix.SOCK_DGRAM 0 in
>   Unix.setsockopt sock Unix.SO_BROADCAST true;
>   let sent = Unix.sendto sock "ping" 0 4 [] (Unix.ADDR_INET
> ((Unix.inet_addr_of_string "255.255.255.255"), 12345)) in
>   Printf.printf "Sent %d\n" sent;
> ) with
>   | Unix.Unix_error (x,y,z) -> Printf.printf "%S - %s,%s\n"
> (Unix.error_message x) y z
> ;;
> I looked around in the OCaml source, and it
> looks like the broadcast address is specifically disallowed unless
> HAS_INET_ATON is defined? Why is this?

Quoting the Linux man page:

  The  inet_addr()  function  converts  the Internet host address cp from
  numbers-and-dots notation into binary data in network byte  order.   If
  the input is invalid, INADDR_NONE (usually -1) is returned.  This is an
  obsolete interface to inet_aton(), described immediately above;  it  is
  obsolete   because   -1  is  a  valid  address  (255.255.255.255),  and
  inet_aton() provides a cleaner way to indicate error return.

Unfortunately, Windows does not provide any of the better substitutes
for inet_addr, namely inet_aton and inet_pton.  Send a bug report to
Microsoft.

> I noticed that when I force the address by replacing:
> Unix.inet_addr_of_string "255.255.255.255"
>
> with:
> Obj.magic "\255\255\255\255"
>
> it _seems_ to work fine. [...]
> And am I breaking anything by using magic?

Currently not.  Inet addresses are represented internally as strings
(of length 4 for IPv4, 16 for IPv6) containing the bytes of the
address in network byte order.  This is of course not guaranteed but
unlikely to change soon.

- Xavier Leroy