Can Not Open Read-Write file again

[Brian Collins]

Hi again,

If you set up a drive via NETDRIVE CONNECT ... D:

and then you crash DOS, or trigger a reboot, or something (basically, any number of things that cause a reboot without some sort of exit hook able to run), you leave the drive connected on the server side, and cannot re-connect to it, because it thinks it's still connected.

It'd be great to have a command option like NETDRIVE DISCONNECT or RESET or something that takes the server:port and DSK image, so you can effectively "unmount" it. This command could come just before the NETDRIVE CONNECT line, thus ensuring that even if you had a hard lock and had to reboot, you'll reconnect without having to shell into the server, disconnect it manually, etc.

I'm sure there's other ways to do this, but the basic problem is that unforeseen reboots require a shell into the server to clean things up.

Brian

[Michael Brutman]

Oh believe me, if you find a usability problem with the code then I already know about it. ;-0

In earlier versions of the code I used to allow the server to allow machine to reconnect automatically, detecting the orphaned session first and cleaning it up before proceeding with the new connection.  That became problematic when I changed the code to allow more than one network drive per client.  To avoid ambiguity I disabled that feature.

What really needs to happen is each drive image on the server side needs its own metadata file that describes what clients are allowed to connect, what the permissions are, if auto-reconnect is allowed, individual timeout and journaling settings, etc.  The current mechanism of just touching a journaling file to start journaling or using the filesystem permissions is simple, but it doesn't allow for the more advanced things that should be done.  But I'm also loathe to make the server too complicated and difficult to configure.

Eventually I'll add an automatic reconnect feature; I need it desperately for my web server.  (If the RaspPi serving the hard drive for brutmanlabs.org stops for any reason then my long term web server test ends, and I hate losing months of runtime.)

-Mike

[Brian Collins]

Automatic reconnect would be nice yeah, but I was thinking a more explicit ability to send commands other than connect to the server, whether it's a separate tool, or an option to netdrive.

Basically, take some of the responsibility off the server. Just a thought.

--
You received this message because you are subscribed to a topic in the Google Groups "mTCP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mtcp/oEAx4oBbXoI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mtcp+uns...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mtcp/b5709e5d-5357-42b7-9fe4-9faa3916a509n%40googlegroups.com.

[Michael Brutman]

And definitely worth suggesting that thought, so don't be shy ...

Besides sending commands to the server from DOS another option for this specific case is to add a -force_reconnect type option on the connect command.

Whatever I do, I want to ensure it is consistent from a usability and security standpoint.  I don't think we're going to ever see more than 2 of these servers running in public, but I want to ensure that I don't give a malicious idiot the ability to send bad commands and kill a server or arbitrary sessions because it is fun.  Not being able to use encryption on the connections makes that challenging to implement.  The long term solution is probably to let the server run in a more open mode when used as a private server, and then save the security restrictions for those 2 anticipated public servers.

Side note: I'm trying to keep the size of the EXE file at about 45K because if it gets larger an unmodified PCjr (112K usable) can no longer run it.  I might need to give up on that.

Mike

[Brian Collins]

That's pretty funny, last night shortly after I sent that, I realized it'd probably be cleaner and less invasive to just have some type of force reconnect option. And yes, totally makes sense there would be other considerations (like malicious intent) that I wasn't thinking of. Anyway, yes, I do like that idea, nice and simple :)

[Tim Sedlmeyer]

There is already an option to set a session timeout on the server side
in case the client disconnects without contacting the server. The
issue with this currently being that if a mounted drive isn’t accessed
within the timeout period the session will be killed on the server and
the client will error when next trying to access the session. Is it
possible to add a noop/keepalive packet type which the client can be
configured to send at a specified interval? This would allow people to
tune these depending upon their specific needs. If you are doing a lot
of development and your client is frequently rebooting unexpectedly,
set the timeouts to a short interval and wait briefly to reconnect. It
isn’t a perfect solution but does overcome the malicious idiot forcing
disconnects issue. You probably would want to add a flag on the server
side whether to respect these timeouts because you don't want someone
connected to a public server remaining connected forever if they
aren't actively using the server.

> You received this message because you are subscribed to the Google Groups "mTCP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mtcp+uns...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/mtcp/CAPAHKi33AriHntO9CDfq6vdoPB16qiE2u7Vjkt5Jje70M8JFQw%40mail.gmail.com.

[Brian Collins]

Hmm, I think I prefer the force reconnect option to having to ping the server periodically, combined with a short session timeout. It's more explicit, and seems a bit less fragile.

Also, if I'm running a CPU intensive program, it's nice to know I don't have to consider/worry about anything like that going on behind the scenes.

To view this discussion visit https://groups.google.com/d/msgid/mtcp/CAK_h9uE5TSayC%2Bc%2BWWieMyr1J_k37CWTW0krOFvdFQ%3DLgCo%3D8Q%40mail.gmail.com.

[Michael Brutman]

BTW, I love these discussions ...  this is the fun part of the hobby.

The keep-alive idea is interesting and I don't think it would be difficult to implement or add any real overhead to the DOS side.  It also lets the server differentiate between a client that is connected but idle, vs. a client that has crashed or is not reachable.  Having a -force reconnect option is also reasonable, at least in home environments.

I have a few things to work on:

• Mostly server side changes to deal with these and related issues.
• Adding read-ahead streaming to try to help performance when you are not near the server.
• Adding a C version of the server for people on older hardware and operating systems.

-Mike