Host/Guest connection problems

[druellan]

Hi! We are testing the emulator, but so far we where unable to connect.

We have the ports open on the router, and we can see the emulator opening the port 7000 and sending a packet, but after that nothing happens until the timeout:

So, we want to double check the service is working or if we can do some tests to try debug the problem.

Thanks for this, BTW. It is crazy that on 2018 there are so little ZX Spectrum emulator capable of network play.

[alangibson27]

First, thanks for contributing this issue!

The discovery service is actually down at the moment - I decommissioned the AWS instance that it was running on. I can take a look at getting it back up and running over the next week or so.

[druellan]

Oh, thank YOU for the effort, and please, no rush. Just let me know when you're ready so we can test and hopefully contribute with some feedback.

Thanks again!

[alangibson27]

Thank-you for waiting! I've moved the discovery service onto a different hosting platform, where I can run it free-of-charge for a year. If you download the latest version, it should in theory be working now.

Let me know how you get on, and if you're still having connectivity issues, I can check the discovery service logs to check if your session requests are making it that far.

[druellan]

Thanks! I'm going to test this week and report back. Thanks again!

[druellan]

Hi again! Sorry the delay. I'm back trying to test the emulator. I just want to be sure the service is up and running, so I can start testing again.

Let me know if I can help on anything. Thanks!

[alangibson27]

Hi Dario,

No problems. The service is ready and waiting for you. I'll be able to check the logs and let you know whether the service sees any connection attempts.

Thanks again, Alan.

[alangibson27]

Hi Dario,

I just took a quick look in the service logs, and it looks like there was a successful connection established between two users - I'm presuming that was you?

How did you get on?

Thanks, Alan.

[druellan]

Thanks!

We tested the emulator briefly with mixed results. Two of my friends where able to connect and test Batty, but they ran into some problems (black screen, freezes). Batty is kind of problematic on other emulators like EmuZWin, and the latency was high between connections, so I want to retests.

In my case, I've got many problems connecting to the server. I'm pretty sure it managed to connect and search for peers on one occasion, but the rest of the time it was "contacting discovery services". I have the ports open in the router, so, I think the problem is my Win10 installation.

Thanks again and I'm going to keep testing!

[alangibson27]

Thanks for the feedback.

I quickly tried a TZX version of Batty, running Plus-F in 48K mode, and it seemed broadly fine, so maybe it was the latency that was the issue.

I did have some problems when I was testing on a Windows machine (I normally run on Linux), and they were to do with the Windows firewall blocking inbound traffic on the Plus-F ports. I had to go into the firewall settings, remove all references to Plus-F, uninstall and then reinstall, and it worked better.

[alangibson27]

I think I've spotted what may be causing the freezes that your friends were experiencing.

Basically, the way the remote 2-player feature works is by sending compressed screenshots over a UDP connection. I've just had a look at some metrics, and these can be 2 or 3 thousand bytes in size. That's quite large for a UDP message, so I suspect that quite a lot of them may be getting dropped.

I'll put a fix in that will split up the screenshot into a number of smaller messages, and see if that makes a difference.

It may take me a little while, and I'll let you know when I'm done.

Thanks again, Alan.

2018年4月14日 11:15:15 に Dario Ruellan notifications@github.com が執筆： Thanks! We tested the emulator briefly with mixed results. Two of my friends where able to connect and test Batty, but they ran into some problems (black screen, freezes). Batty is kind of problematic on other emulators like EmuZWin, and the latency was high between connections, so I want to retests. In my case, I've got many problems connecting to the server. I'm pretty sure it managed to connect and search for peers on one occasion, but the rest of the time it was "contacting discovery services". I have the ports open in the router, so, I think the problem is my Win10 installation. Thanks again and I'm going to keep testing! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[druellan]

Thanks! No problem! I'll wait :D

Besides, I'm still not able to contact to the discovery service on my machine (181.231.144.140). Tested on two Windows installations, so, I'm pretty sure is my router, or my ISP is perhaps doing something. I need to investigate further.

[alangibson27]

I've just uploaded version 1.5.4 of the emulator, which has the fix to break up the emulator state into smaller and hopefully more UDP-friendly packets. You can get it from http://plus-f.socialthingy.com/download as before. Let me know if that makes any difference. Status messages in the bottom of the window will show packet sizes and delays as well. The largest packet size I've seen is ~600 bytes, which should be fine.

I've also had a check in the discovery service logs, and there's no sign of any data arriving from 181.231.144.140, which makes me suspect the packets are being dropped on the way to the discovery service.

[alangibson27]

Just a quick follow-up, I've seen two entries in the logs for sessions with the IDs test and test2 from 181.231.144.140 on April 16th, but no partner ever joining either session. Obviously I can't say whether the "wait for the other side" message got back to the session initiator, but the initiation definitely happened on the server side.

[druellan]

Hi! New update.

First of all. My problem trying to connect to the server: that got solved once I uninstalled the previous version to install the new one. That forced Windows Firewall to ask again about permissions, and after that, everything started to work, so, might be related.

The rest was also a success, we where able to connect and play perfectly. The first game, Batty, gave us some problems, not sure why, the guest was no able to control anything. We switched to Target Renegade, that worked flawlessly.

One thing I noticed: if the guest drops the connection for some reason, is not going to be able to reconnect to the same session. The host must disconnect and create the session again.

Exploding Fist + gave us some trouble, and I've noticed that for some reason, after so much back and forth between host and guest joystick configurations, the keyboard become corrupted: for example the double-quotes (") started to type as single quotes (´). An app restart fixed that, and the game showed no problems.

So, I'm going to keep an eye about this last thing, but overall, excellent. Good work!

[alangibson27]

That's great news, glad you're able to play some games!

I'll take a look at Batty to see if there's anything specifically there that would be preventing the guest from doing anything.

As for the guest reconnection problems, I could probably add a reconnect option that would allow the guest to connect to the host again.

[druellan]

I'll take a look at Batty to see if there's anything specifically there that would be preventing the guest from doing anything.

That was the first game we tested, so, might be our fault.

As for the guest reconnection problems, I could probably add a reconnect option that would allow the guest to connect to the host again.

To be clear, the problem was not the guest but the host. The host must recreate the session, otherwise the guest cannot reconnect again, even if you close and reopen the app. Looks like a handshake problem.

[alangibson27]

To be clear, the problem was not the guest but the host. The host must recreate the session, otherwise the guest cannot reconnect again, even if you close and reopen the app. Looks like a handshake problem.

Right, I see what you mean. That was actually sort of a design choice, in that the session information is wiped from the discovery service as soon as the host and guest have made their connection. It wouldn't be too hard to keep the sessions around for some period of time though, say 10 or 20 minutes, so that reconnection would be possible.

[alangibson27]

Almost a year on, but there's now a Reconnection option on the Network menu that allows reconnection with the previous guest/host (provided of course that that guest/host is still running).