• Please review our updated Terms and Rules here

Call for ideas/fixes for the next mTCP version

533k3R said:
To what degree? Sounds interesting, anyway.
Click to expand...
CGI is a simple protocol: Set a few environment variables, execute a program, and send the program's output back to the client. (Plus some error handling.)

Egzoset said:
Add a flag to force 'HDCP.EXE' to BootP/DHCP and perhaps even create 'mTCP.CFG' if not found.
Click to expand...
You already need MTCP.CFG file for DHCP.EXE to know where the Packet Driver lives, it doesn't function without it. I wonder if there is a reason to support BOOTP at all, I can only imagine dialers like EPPPD.EXE... but those are no longer useful?

MiaM said:
You could use the date on certain existing files to determine that the time/date must at least be that of those files.
Click to expand...
Since the DHCP client always writes to MTCP.CFG, it can be used as a reference. If the system time is before the MTCP.CFG time (within a week or so), DHCP.EXE could set the clock to the MTCP.CFG time and warn the user. Having this reference is only relevant for encrypted communication, though. On the other hand, most HTTP servers will send their current time as a header for cache expiration reasons.

mbbrutman said:
I talked about it with somebody recently and it [LPR] is more difficult to do than it looks.
Click to expand...
Can't you just open the socket when the first byte arrives, and close it after a reasonable timeout? But I do understand the problem of implementing any TCP/IP background services with mTCP.
 
MiaM said:
Btw re computers without a working clock:
You could use the date on certain existing files to determine that the time/date must at least be that of those files. Like use time+date from the file that the dhcp client writes it's output to to set the clock if the clock is set to something before 1990 or so, perhaps?

Unless you already have done so, maybe combine a ntp client with the dhcp client, to do both in one go?

Note that some other protocols can also provide time, but they require a lot more stuff. For example NetBIOS, including NetBIOS over TCP/IP, cam provide time. (NET TIME \\server /SET /YES is a good idea to have in some startup script). I doubt that people who already have SMB running on their network would be that interested in also running mTCP rather than the classic SMB clients, but still.
I don't know which other network protocols and whatnot provided some network time/date. Perhaps Netware?

You could also do an ugly hack and just set the clock to a day before the expire date/time of the DHCP lease if the clock is obviously incorrect.
Click to expand...

It's generally easier to just run DHCP once, run SNTP, and run DHCP again to update the timestamp in the file. I think about a combined DHCP and SNTP client on occasion because they both just need UDP but that makes for a larger program and I'm trying to keep things small. Hard drive based systems run the programs fast enough where running DHCP twice is not an issue; it's only when you run from floppy drives when you have time to tap your fingers while waiting for the process.

In general I'm trying to follow the Unix philosophy of utilities - keep them small and do just one thing well.
 
maxtherabbit said:
I recall several years ago you mentioning the feasibility of an LPR printing redirector as a potential mTCP utility, is this still on the radar?
Click to expand...
This seems like a better match for any TCP/IP implementation that is already a TSR though?
 
Svenska said:
Since the DHCP client always writes to MTCP.CFG, it can be used as a reference. If the system time is before the MTCP.CFG time (within a week or so), DHCP.EXE could set the clock to the MTCP.CFG time and warn the user. Having this reference is only relevant for encrypted communication, though. On the other hand, most HTTP servers will send their current time as a header for cache expiration reasons.
Click to expand...
It seems more useful to use the date of the MTCP.CFG file if the clock is incorrect by decades, but not if it's off by a few days though?
 
MiaM said:
It seems more useful to use the date of the MTCP.CFG file if the clock is incorrect by decades, but not if it's off by a few days though?
Click to expand...
Why do you consider "wrong by decades" worth fixing, but "wrong by two weeks" not?

You can reasonably assume that the MTCP.CFG file date is not in the future, so the idea sketched above will always improve the situation, no matter the difference. Many TLS certificates fail to validate quite early (30 days), so I see a shorter cut-off as good.
 
Svenska said:
CGI is a simple protocol: Set a few environment variables, execute a program, and send the program's output back to the client. (Plus some error handling.)
Click to expand...
You're saying he's implementing basic CGI.

So, to the degree of Basic CGI; As would be my assumption, too. But, I try not holding the guy responsible for Netdrive down to any of my assumptions. He seems clever :)
 
Deleting was probably over correcting - I undeleted it and moved it to a new thread. After I'm done traveling, I'll give you a detailed reply there.
 
Svenska said:
Why do you consider "wrong by decades" worth fixing, but "wrong by two weeks" not?

You can reasonably assume that the MTCP.CFG file date is not in the future, so the idea sketched above will always improve the situation, no matter the difference. Many TLS certificates fail to validate quite early (30 days), so I see a shorter cut-off as good.
Click to expand...
It would be decades in the future if you don't set the clock on an XT that hasn't got any clock or on a computer with a failed/removed CMOS battery. Or for that sake on a computer where the BIOS isn't Y2K compliant (and for some reason there is no Y2K compliant hardware clock driver installed).
 
You must log in or register to reply here.
Back
Top