search

ADTPro / adtpro

Apple Disk Transfer ProDOS (ADTPro)
http://adtpro.com
GNU General Public License v2.0
132 stars 19 forks source link

macOS as Ethernet server is highly unreliable #60

Open bernstbj opened 5 years ago

bernstbj commented 5 years ago

Though I'm doing this nowadays on High Sierra (10.13), the situation was the same on the last few major releases of OSX. In general, running as an Ethernet host results in "host timeout" or other connection drop issues most of the time. However, if I run a Windows 7 VM as the host on the same machine, I don't experience this issue (yes, pointing to same disk directory). It doesn't matter if I'm using the legacy Java 6 or the more up-to-date Java 8 VM.

I'd be happy to try and take a look at the code myself, but would more want to confirm whether or not this is a known issue in the first place and if anyone has looked at it.

david-schmidt commented 5 years ago

It's not something anyone has looked at, so by all means, feel free!

bernstbj commented 5 years ago

Funny, but a trial run with your debug messages un-commented, rebuilt and run locally with trace enabled resulted in no errors for the first attempt. However, a subsequent test with trace OFF didn't work.

I didn't dig very deep, but are you using UDP for all communications? If so, is there any particular reason why? Seeing that the problems appear to be dropped packet related, I'm curious why TCP wasn't used?

thanks

david-schmidt commented 5 years ago

Given the name of the class UDPTransport.java, yep, it's UDP. Likely historically related - we have the capabilities of the (original) Uthernet card as well as the IP65 stack; both grew in capabilities over the many years since this all started. Any change will require both sides of the conversation to be updated.

ep00ch commented 5 years ago

bernstbj, The UDPTransport sends the packet number as it's first byte. Unfortunately, the client doesn't do any packet reordering, or checking for dropped packets. It just checks to see if the new packet is a duplicate of the previous packet. It is possible that if packets are arriving out of order or are getting dropped, that the client is timing out and having problems. I agree that UDP is not well suited for the transfer of this kind of data, but I am sure it was far easier to implement on the Apple II. I don't know of this is the issue though. I did some work on an ADTPro TCP server (basically Virtual Serial over IP running as a server), but I did not build a UI for it. On my setup, I use an internet modem connected to the Apple SSC, and the Serial client. You can use virtual serial on ADTPro to do basically the same thing and have a real TCP connection. Now that IP65 has a c interface, a real Apple II TCP client wouldn't be too bad to write.

KrisKennaway commented 5 years ago

Getting a packet trace with e.g. "tcpdump -i en0 -w tcpdump.out -s 0 port 6502" (or whatever is your ethernet interface, if not en0) may shed some light on what is going awry.

KrisKennaway commented 5 years ago

BTW in terms of future enhancements, it would be useful to maintain a running CRC across each packet, to better detect missing/reordered packets or other corruption (currently the CRC is computed independently per packet).

e.g. IIUC, currently if the UDP packets arrive out of order they will be silently accepted, leading to a corrupt transfer.