Subj : EtherDFS and record locking is no-go for BBSs
To   : J0hnny A1pha
From : AKAcastor
Date : Tue Feb 27 2024 12:25:34

 ja> I kow this was the general consensus, but I reached out to the author of
 ja> mTCP for this question: can I use etherDFS for a multi-node BBS?

Thanks for getting a conclusive answer on that.  I wonder how correct record locking for network access would work - maybe we could add that on the server side?

 ja> I'm moving on to MSCLIENT...

Overall MSCLIENT has been working well for me, but I am having problems where after some time the network drive becomes inaccessible with "Too many open files" as an error in DOS.  If I do a 'net logoff' and 'net logon' and 'net use' to remount the share then it works again.

It's been a frustrating problem and I am having trouble finding the cause (or more importantly, a solution).  It's happening under both DOSBox-X and 86Box, running MS-DOS 6.22 in both.

Other than this "it stops working eventually", the setup has worked well. (multiple nodes of the BBS are sharing message bases, etc, without corruption)

 ja> But I'd much rather use mTCP (for TCP/IP) and XFS (for NFS v2) under MSDOS
 ja> 6.22, but not sure how to "share" the packet driver? I've seen PKTMUX
 ja> mentioned, but it seems like the use case is DOS + Win3.11 packet drivers.

I haven't run XFS, I am curious how well it works and if SHARE.EXE record locking works.

PKTMUX looks interesting, I am a bit nervous about the extra complications it may bring, getting stable networking can be tricky enough, combining network stacks seems like a bold move. :)

The limited conventional memory is definitely an issue (for sure with MSCLIENT), I am finding it workable but not exactly luxurious.  I am running QEMM to get a bit more conventional memory but it's still tight.


Chris/akacastor

--- Maximus 3.01
 * Origin: Another Millennium - Canada - another.tel (21:1/162)

.