Stone
10k Member
I like U - N E T II for a Server/Workstation based network. It can use anything from a PC on up through 486 and PS/2. And it's parallel port so no NICs are required. DOS 3.3 or higher is recommended.
Let us know please.
* A DOS server to be able to have a peer to peer vintage computer network.
* Make it work with PC/MS-DOS 3.1 and higher. Actually, I have not tested it with those DOS versions but you said it requires DOS 5.0+
* A DOS server to be able to have a peer to peer vintage computer network.
* Make it work with PC/MS-DOS 3.1 and higher. Actually, I have not tested it with those DOS versions but you said it requires DOS 5.0+
It doesn't seem to be out in the wild so I'll send you a link.Stone would you mind posting a link? I can not find anything with that name.
Unfortunately my initial tests with 8088 systems (which work 100% with mTCP) have not been very promising. On a PCjr with a Xircom PE3, the driver appears to load, but it occasionally truncates a byte from the stream, which means I can't rely on it for anything. When I copy a file to the local drive, then copy it again, then run a file compare, they don't match up. Example:
https://photos.google.com/photo/AF1QipOvM9aqBiU5PfmnaZwzerR_sd9SuXkGTxy-EpG6
Looking at PROTOCOL.TXT, it appears that etherdfs's protocol does not contain any error-checking/checksum whatsoever, so until this is added, etherdfs is unusable for me. And, honestly, I don't think it should be relied on for anything other than tinkering until this is added. No network is 100% perfect.
On a real IBM PC 5160 with an Intel Etherexpress 8/16, the driver hangs while initializing. This might be because the NIC is connected to a wireless adapter, but again it works with mTCP perfectly so I'm not sure where the trouble is. I've double-checked the MAC is correct, but it just sits there:
Looking at PROTOCOL.TXT, it appears that etherdfs's protocol does not contain any error-checking/checksum whatsoever, so until this is added, etherdfs is unusable for me. And, honestly, I don't think it should be relied on for anything other than tinkering until this is added. No network is 100% perfect.
On a real IBM PC 5160 with an Intel Etherexpress 8/16, the driver hangs while initializing. This might be because the NIC is connected to a wireless adapter, but again it works with mTCP perfectly so I'm not sure where the trouble is. I've double-checked the MAC is correct, but it just sits there:
The author already stated no DOS server will be written by him.
Also, the DOS network redirector interface wasn't really usable until 4.x, so you should be using 4.x or higher with this.
[*]Rewrite the client in assembly. Not necessarily to reduce its size, but rather to make it faster and easier to read and maintain without C or compiler/stack tricks.
In theory the packet driver will not ever see an Ethernet frame that was corrupted in flight because it will fail the CRC check.
So for a local network your biggest danger is packet loss, not packet corruption.
You can get really good throughput with this technique, assuming no packet drops. To make it more robust you have to start adding sequence numbers, re-transmission, and error detection. That leads to dead time on the wire, which then leads to implementing sliding windows for the packets. By the time you get to that you might as well have just implemented TCP/IP which features all of those things and is a universal standard.
57 | S | a single byte with a "sequence" value. Each query is supposed to
| | use a different sequence, to avoid the client getting confused if
| | it receives an answer relating to a different query than it
| | expects.
While the Ethernet CRC should protect you, it is still inadequate. (...)
I corrected the photos in my previous post.
So there are two concerns:
This https://goo.gl/photos/fRUzQKaEG5PWqMny6 shows that sometimes a byte is silently lost. The photo shows the same 512K file transferred only twice. If you want to argue that my hardware is bad, then that's the end of that conversation, although I'm not sure how I'm expected to fix it.
My second concern is that the driver completely hangs on initialization on a real PC with a "real" ethernet card (Intel Etherexpress 8/16). That system is not running any other network redirectors at all (no other network sharing, no mscdex, no cdrom drive, no parallel-port devices), and it runs IBM PC DOS 2000 (ie. IBM PC DOS 7.00, revision 1). The cards in that system are an IBM CGA, Intel NIC, Sound Blaster Pro, ADP-50 IDE hard drive adapter, floppy controller, Central Point option Board. I will trace through driver initialization to see if I can pinpoint where it is locking up.
On the system where it is hanging, I have the NIC connected to a wireless bridge. I will test connecting it wired to see if that fixes the problem.
This https://goo.gl/photos/fRUzQKaEG5PWqMny6 shows that sometimes a byte is silently lost. The photo shows the same 512K file transferred only twice. If you want to argue that my hardware is bad, then that's the end of that conversation, although I'm not sure how I'm expected to fix it.
My second concern is that the driver completely hangs on initialization on a real PC with a "real" ethernet card (Intel Etherexpress 8/16). That system is not running any other network redirectors at all (no other network sharing, no mscdex, no cdrom drive, no parallel-port devices), and it runs IBM PC DOS 2000 (ie. IBM PC DOS 7.00, revision 1).
I would be surprised if EtherDFS was loosing bytes in such manner
I will do some prototype very soon - would be great if you could test it out to see if it makes things better for you.
I didn't test PC DOS at all - the only OSes I tested EtherDFS on were FreeDOS and MS-DOS (v5.x, v6.x and v7.x), hence it may be very possible that PC-DOS does something slightly differently.
While the Ethernet CRC should protect you, it is still inadequate.
I've helped people debug quite a few old machines where the packet driver presented corrupted data to the application. Being that it was somebody else's machine I could not do a root cause analysis, but it was very clear that they were dealing with bad hardware. What you really need is end-to-end protection. The TCP/IP checksums get you closer to that by ensuring that not only is the Ethernet CRC working, but the interface to the host machine and the host machine itself are working properly. A real end-to-end solution is using MD5 to compare checksums after it is written to disk. Zip files are great for data transfer in this regard because their CRC will detect pretty much any error in the entire process.
Trixter might have bad hardware, but given that FTP is working well it can't be that bad. Even with good hardware you are going to have errors at various stages of the data transfer, which is why it is advisable not to rely on just the Ethernet CRC. You have to assume the hardware is trying to sabotage you.