cheesestraws
Well-known member
Yeah, the LToUDP protocol doesn't require it because we've already got a UDP checksum in the packet header, and there's no point making the receiver calculate another checksum, especially a perverse one. This is, I'll admit, partly because I looked at the SDLC CRC in Inside Appletalk and just thought .... "or, hear me out, I could not implement that".
If receiver.py sends the FCS out onto UDP that's not following the protocol. AirTalk, for example, does do FCS validation and strips/adds it, so if you send an extra FCS to AirTalk, the extra FCS will make it through to the client's AppleTalk stack as junk data. Whether that stack cares probably doesn't matter, but in the cases of large file transfers, it could make packets overlength, in theory. That's a good find, @NJRoadfan.
Now I come to think of it, @tashtari, could that partly account for why you were seeing weird slowdown between mini vMac and your tashtalk prototype when copying files (which I couldn't reproduce?)
If receiver.py sends the FCS out onto UDP that's not following the protocol. AirTalk, for example, does do FCS validation and strips/adds it, so if you send an extra FCS to AirTalk, the extra FCS will make it through to the client's AppleTalk stack as junk data. Whether that stack cares probably doesn't matter, but in the cases of large file transfers, it could make packets overlength, in theory. That's a good find, @NJRoadfan.
Now I come to think of it, @tashtari, could that partly account for why you were seeing weird slowdown between mini vMac and your tashtalk prototype when copying files (which I couldn't reproduce?)