Multicasting (luasocket) is not working on windows.

Issue #1216 resolved
created an issue

I can send multicast data using love and receive it using python, but I cannot multicast.

local socket = require"socket"
local group = ""
local port = 12345
local c = assert(socket.udp())
print(assert(c:setsockname("*", port)))
print(assert(c:setoption("ip-add-membership", {multiaddr = group, interface = "*"}))) -- error
while 1 do

Comments (33)

  1. Alex Szpakowski

    LÖVE, like most other software, tends to only use official releases of software dependencies since there are likely bugs and shifting behaviour in unreleased software (like luasocket 3, which is still in Release Candidate status after 3 years...)

    Maybe someone can make a small patch of the fix from luasocket 3 that can be applied to luasocket 2's code, though?

  2. Alex Szpakowski

    Can we just use the newest version?

    Can you verify that there are no regressions in the latest 3.0-rc1 compared to what LOVE currently uses?

    (And if there are none, why hasn't it been released yet?)

  3. James Watkins-Harvey

    Have checked the proposed patch at github. The diff contains more changes than required (luafilesystem), and the changes related to luasocket appears to be incomplete; for example, no preload declaration has been defined in luasocket.cpp for new lua files added in libluasocket. The fix might work locally, but only if another copy of luasocket 3.0rc1 exists elsewhere on lua's include path...

    @buckle2000 Would it be possible for you to try the following patch . I had it compile on OS X, but haven't yet tried on Windows. Given that you have interest in updating luasocket, maybe you can validate this patch?

  4. James Watkins-Harvey

    @Alex Szpakowski According to luasocket's author, the reason for not publishing on official release is simply that there is always new features coming in... Actually, out of 32 open tickets in the luasocket's issue tacker, about one third of them relates to the fact that there has been no recent official release or that official documentation is outdated. And about the remaining 20 tickets (or so)? I would say that most of them are either feature requests, complains about build issues in some off-the-chart environment, or actually non-issues reports.

    The only serious issue at present time, I think, might be the fact that port number is not provided in the Host header in HTTPS queries on non standard ports (tickets 169 and 172). I don't know if it is a regression from the release 2, though.

  5. James Watkins-Harvey

    No, I did regenerate all *.lua.h files, and a few new ones were created.

    Do you have an error message? Can you show the code you use?

    Also, be aware of the fact that luasocket no longer expose itself through global variables. For example, instead of:

    require "socket"

    you should now opt for something more like:

    local socket = require "socket"
  6. James Watkins-Harvey

    Finally, there was no commit mistake, every files are there.

    Your code seems to work fine on my side, well as far as I can check; had to change the group address however (I used ""; don't know what it is used for, but I had already a local process using it), and I don't have personal experience programming multicast sockets, so I don't know how to test the code more throughly. Still, after changing the group address, I do no longer get any error message.

    You said that the very same code works fine on your github branch? Maybe some new files are not being compiled? I had to make some minor modifications to the XCode project to build it on OS X, but haven't yet altered build process for other platforms. Can you try setting a different socket option? Something simple such as SO_REUSEADDR should do the job: basically, if you can successfully set any socket option, then that should indicate that the luasocket library itself is complete and working... Also, is it possible for you to run your lua code with a brake point set on libluasocket/options.c, line 260?

  7. buckle2000 reporter

    The group address is just like the name of a group, one must know it to join the group.

    You said that you "had already a local process using it", which is not possible. Only a port can be occupied, not a multicast address.

  8. James Watkins-Harvey

    As I said, I don't know much about IP multicasting, so maybe I use incorrect terms...

    What I mean is that I first checked at netstat -g, and got:

    Link-layer Multicast Group Memberships
    IPv4 Multicast Group Memberships
    Group                   Link-layer Address  Netif             <none>              lo0               <none>              lo0

    So I used an address from that list, expecting that it should be valid... Is that assumption correct? I had an invalid argument error with your original group address, but succeeded with one of the above address...

  9. buckle2000 reporter

    That is strange... I know nothing about netstat but I can join any multicast address.

    What is that error message about? I think the real reason of that problem is you opened love process twice running the same script, but sometimes love will not terminate even if there is no window of it.

  10. James Watkins-Harvey

    Seems you are right... Trying again now, I can use your original group address. That could be indeed I had several instances of the program running... I started love using various methods (one inside the Eclipse LDT's debugger, one inside XCode and one in command line with dtrace) so though I don't rely on actually having a window being visible, there is certainly a possibility that I had more than one instance running at the same time.

    Anyway, this means that it works fine on my side... Have you had any luck with the update cmake file list?

  11. James Watkins-Harvey

    Well, at least it compile... Does any setoption() fails, or only ip-add-membership?

    I dont have access to a Windows machine at present time, so I can't do much myself past this point. Would it be possible for you to run love and your love program inside Visual Studio's debugger? You could set brakepoints at various point in libluasocket/options.c .

    You should also have a look at the content of the global variable package.loaded. On my side, I have:


    All of these should be tables, and contain among other things a _VERSION property.

    Finally, check the metatable on c (that is, the return value of socket.udp(). Does it contain the setoption() function?

  12. James Watkins-Harvey

    I'm trying to understand how your branch differ from mine in any way that would explain this issue... Given that the luasocket code itself is the same, and that differences in how the lua code is being loaded, then it appears that it must a build time difference. How exactly did you build luasocket for use inside love in your branch? I see no modification to love's build script... I guess you ran luasocket 's makefile, but then how did you get love to use those binary files?

  13. Log in to comment