LÖVE

Hello all.

I am playing with LUBE (-sigh-) and trying to get it working right.

I am doing a test, where I have two squares - a red one and a blue one - which can be moved around with the keyboard.

Whenever a client moves it's square, it sends the new x- & y-positions to the server, which then broadcasts the new positions to the other client.

All of this seems to work (except for some "performance issues", which I guess is a question for another time).


Here's my procedures:

All on the same computer~
1. Start the server-program
2. Start two instances of the client-program
3. Connect with IP: localhost / 127.0.0.1 / <my external ip from WhatIsMyIPAddress>
4. Great success and happy times!


On two different computers~
1. Start the server-program on PC_A
2. Start one instance of the client-program on PC_A
3. Start one instance of the client-program on PC_B
4. On PC_A client-program, connecting with anything from the procedure above works
5. On PC_B client-program, connecting with anything at all, doesn't seem to work.
6. Miserable defeat!


I have tried using Hamachi between my own 2 laptops and between me and a friend. No success.
I have also tried connecting my own 2 laptops with a cross-over LAN-cable and with static IP's on the interfaces. No success.
And of course, I have tried connecting my own 2 laptops, using the local IP (DHCP; from the router).



Now my head tells me, that it's not a problem with my router/firewall (since I couldn't even connect between cross-over LAN-cable). But that might just be way off.


Am I just using LUBE entirely wrong?


I hope to get some clarification on this, as it would be really cool to do some multiplayer projects!


Cheers,
Ragerin


I have attached my .love-files for the server and the client.

Nope, you just need to port-forward your server! Just like when hosting a Minecraft server!

EDIT: Also, really good work on the program! May I try to use this frame-work in one of my games?

Really? So if I don't have access to my router (we live 2 couples in one house, and the other couple have the router), there's no chance for me using UDP? Or are there any ports or trick to use?
I have encountered something called "UDP Hole Punching" but I'm not sure of the principals and if it'll work with Löve and LUBE?


And thanks! It turned out okay, although there "opponent" square doesn't have fluent movement. But that should be easy to fix. And of course you can use it! =D I would be honored!

Ragerin wrote: I have encountered something called "UDP Hole Punching" but I'm not sure of the principals and if it'll work with Löve and LUBE?

Yes, this is possible, I've done it, for example. That said, it's not guaranteed to work, and is a bit of a hassle to set up, the basic idea is that you've got a 3rd party both sides connect to, and that 3rd party negotiates between them, telling both sides who they want to connect to. Due to the way NAT works, if both sides start sending messages to each other using the right ports and ips after a few (arrived) packets the messages should show up on both sides, after which you can just have a normal connection.

Maybe you can see if your router supports upnp, though, because there's upnp tools around that let you use upnp to negotiate port forwards.

So if I want an easily out-of-the-box working network client-/server-setup, I should not use UDP, but TCP, thus eliminating this issue? Or is it the same story with TCP connections (I mean, they are after all ACTUAL connections, right?)

There's one thing I don't understand, though; how come that when connecting 2 PC's with a cross-over (just in case the NIC doesn't support auto MDIx) LAN-cable and disabling all the other interfaces and deactivating Windows Firewall and AV-software - it still doesn't work? I mean, if this is a problem with the router, then it should work when on a secluded LAN, using static IP-addresses with-in the same subnet?


Thank you guys for all the help so far - it's good to get some clarification on this topic!

Ragerin wrote:So if I want an easily out-of-the-box working network client-/server-setup, I should not use UDP, but TCP, thus eliminating this issue?

Actually, hole punching is impossible with TCP, so you'd actually need to forward.

Ragerin wrote: There's one thing I don't understand, though; how come that when connecting 2 PC's with a cross-over (just in case the NIC doesn't support auto MDIx) LAN-cable and disabling all the other interfaces and deactivating Windows Firewall and AV-software - it still doesn't work? I mean, if this is a problem with the router, then it should work when on a secluded LAN, using static IP-addresses with-in the same subnet?

Yes, that is weird.

bartbes wrote:Yes, that is weird.

Indeed.

Do you have any ideas what this can be?

bartbes wrote:

Ragerin wrote: I have encountered something called "UDP Hole Punching" but I'm not sure of the principals and if it'll work with Löve and LUBE?

Yes, this is possible, I've done it, for example. That said, it's not guaranteed to work, and is a bit of a hassle to set up, the basic idea is that you've got a 3rd party both sides connect to, and that 3rd party negotiates between them, telling both sides who they want to connect to. Due to the way NAT works, if both sides start sending messages to each other using the right ports and ips after a few (arrived) packets the messages should show up on both sides, after which you can just have a normal connection.

Maybe you can see if your router supports upnp, though, because there's upnp tools around that let you use upnp to negotiate port forwards.

Sorry for posting on an old thread, but I have been looking for a tool like this (using upnp in love), could you point me to it?