[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Problem in Lua for Windows with UDP multicast receive
- From: Tim Channon <tc@...>
- Date: Fri, 03 Oct 2008 17:19:33 +0100
Herbert Leuwer wrote:
> I would like to come back to this issue. In the meanwhile I have tested
> the same script
> in the following environments. The behavior of the call
> udp:setoption("ip-add-membership", "224.0.0.1")
> is as follows:
>
> 1. QNX: setoption(...) works and multicast reception as well
> 2. Lua For Windows: setoption(...) fails
> 3. Cygwin: setoption(...) works and multicast reception as well
>
> My feeling is that cygwin uses the correct header/library combination.
>
> So my question to the developers for Windows would be to investigate
> this issue in
> their source code environment and hopefuly be able to fix this problem.
Herbert Leuwer kindly sent me a test script which I have now used to
provide a result. Error goes away.
Test setup is as follows
XP pro.
Lua 5.1.4 and LuaSocket sources
Static linked executable where development setup is known stable
Two compiler chains
1. Open Watcom 1.7a
2. mingw32
Link is with ws2_32 which is the most commonly used bsd socket 2 library
(put another way, that's the win32 socket dll)
Both mingw and watcom executables produce the following result on
running the script, exhibiting the fail.
"Adding membership on interface 127.0.0.1 to IP Multicast group 224.0.0.1
gpsl: mc_receiver.lua:76: setsockopt failed
stack traceback:
[C]: in function 'assert'
mc_receiver.lua:76: in function <mc_receiver.lua:34>
(tail call): ?
[C]: ?"
Changing two lines in Luasocket wsocket.h
>From this
"#include <winsock.h>
/*#include <Ws2tcpip.h>*/"
To this
"#include <winsock2.h>
#include <Ws2tcpip.h>"
Both mingw and watcom executables now produce the following result on
running the script, which is I assume correct behaviour.
"
Adding membership on interface 127.0.0.1 to IP Multicast group 224.0.0.1
Receiving lines ..."
The above suggests Multicast now works. I have been using the changed
header for a few days without seeing any difference in normal Luasocket
use here. In fact last night the above executable was briefly serving
special web pages live on the Internet.
Obviously tests are needed using a Microsoft compiler producing a
dynamic socket library and also any socket tests for general operation.
Luasocket is an excellent library and minor problems will appear, get
fixed and the library becomes even more trusted.
In this instance it is tempting to blame Microsoft for getting it wrong,
but this is very unfair as should become clear from reading the earlier
cited documents. The standard changed and they kept backwards
compatibility on old software, can be compiled for old or new. Mixing is
not a good idea as we just learnt. In a way the real problem is
inadequate documentation, yet once something is out in the wild recall
is impossible. What has happened is just one of those things.