31 Dec
2010
31 Dec
'10
2:50 p.m.
Greetings ...
I am still working on my TCP/IP for DOS. It has been over five years
now. :-)
For the past few days I've been testing an FTP server. The server is
running on a PCjr with DOS 3.3, a SCSI Zip 100 for mass storage, and a
Western Digital WD8003 Ethernet card. (The Zip is attached using a
parallel-to-SCSI adapter and the WD8003 is on an ISA bus adapter.)
The FTP server supports most of the standard commands. If you use
anonymous FTP you will be limited to a 'sandbox' on the Zip drive that
is 30MB in size. You can leave files in the '/incoming' directory -
everything else is read only
Six people can be connected at a time, but the machine can only transfer
data at about 25KB/second so if multiple people start data transfers it
will get painful really fast. That's just a limitation of the machine -
a faster machine would do a much better job. (A TCP/IP socket with this
machine can transfer at data rates up to 100KB/sec. The Zip drive can
so sequential reads at around 50KB/sec. So I figure that 25KB/sec isn't
that unreasonable.)
If you'd like to try out some of your favorite FTP clients I'd
appreciate the extra testing. You can get to it at 96.42.228.74 on port
2021. Browser users can use ftp://96.42.228.74:2021/ for a URL. If you
are curious as to how the machine is performing or who is on the machine
try the 'SITE STATS' or 'SITE WHO' commands.
Chuck(G) has already broken it once by using DOS reserved names that I
forgot to filter. That bug, and an obscure timing window related to
passive data connections have been fixed. If I can keep it running for
another day or two with reasonable traffic I'll consider it a success.
Thanks!
Mike
31 Dec
31 Dec
4:20 p.m.
For the past few days I've been testing an FTP
server.
You need to get a gopher server up and running. Not only is the protocol
ridiculously simple, it completes the retrocomputing circle to use
"obsolete" hardware with an "obsolete" protocol. :)
I connected to the FTP server and I'm rather impressed with its performance.
Maintainer of gopher.floodgap.com (founded as gopher.ptloma.edu in 1999),
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- I put the fun in funeral. --------------------------------------------------
5:04 p.m.
On 12/31/2010 10:20 AM, Cameron Kaiser wrote:
Somehow I missed the Gopher phase. I went from FTP and Telnet as an
undergrad (1989-1992) straight to a dark basement in IBM, and did not
emerge again until 1995 or 1996. By then we were dabbling with HTTP.
As for the PCjr, it seems to be happy at the moment. I won't know if I
screwed up anything until I read the debug log. I have some warning
messages for unusual situations that I look for - if anything else goes
wrong I have to try to reconstruct the situation.
A big part of the process isn't getting the TCP/IP code correct, but
learning how to program in this environment. Buffer space is limited
and most events are asynchronous. The programming environment is pretty
barren - the lack of threading would probably be the most jarring
limitation for a programmer used to current systems. That means keeping
a lot of state per connection, constantly polling, and avoiding
operations that can block for a long time.
Gopher and HTTP will probably be easier now that I have got most of the
techniques down. Gopher is possible. HTTP probably is not worth doing.
Besides the novelty of it, HTTP isn't practical on hardware like this.
FTP client and server is somewhat useful, and I need an FTP server so
that I can do online maintenance for a telnet BBS that I'll finish in
another 5 years.
-Mike
For the past
few days I've been testing an FTP server.
You need to get a gopher server up and running. Not only is the protocol
ridiculously simple, it completes the retrocomputing circle to use
"obsolete" hardware with an "obsolete" protocol. :)
I connected to the FTP server and I'm rather impressed with its performance.
Maintainer of gopher.floodgap.com (founded as gopher.ptloma.edu in 1999),
7:32 p.m.
A big part of the process isn't getting the TCP/IP
code correct, but
learning how to program in this environment. Buffer space is limited
and most events are asynchronous. The programming environment is pretty
barren - the lack of threading would probably be the most jarring
limitation for a programmer used to current systems. That means keeping
a lot of state per connection, constantly polling, and avoiding
operations that can block for a long time.
Well, that's what I mean. Gopher is about the world's easiest protocol.
The client sends you a selector on a single line, you reply with data and
the connection closes. No authentication, no state (except for the state
of the socket itself), no headers, no wacky encodings. You can doll it up
but even dolled-up gopher has all the dolling-up done on the data side
responding to custom selectors; the actual command-response model is still
just that simple.
This is part of the reason I don't like the increased reliance on HTTP
because HTTP is being turned into something that it isn't. For example,
WebSockets? Really?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- And if I claim to be a wise man/it surely means that I don't know. -- Kansas
7:56 p.m.
On 12/31/2010 1:32 PM, Cameron Kaiser wrote:
Well, that's what I mean. Gopher is about the
world's easiest protocol.
The client sends you a selector on a single line, you reply with data and
the connection closes. No authentication, no state (except for the state
of the socket itself), no headers, no wacky encodings. You can doll it up
but even dolled-up gopher has all the dolling-up done on the data side
responding to custom selectors; the actual command-response model is still
just that simple.
This is part of the reason I don't like the increased reliance on HTTP
because HTTP is being turned into something that it isn't. For example,
WebSockets? Really?
I haven't looked much at HTTP, and I know almost nothing about Gopher.
(I have some reading to do - I am a U of M grad!) But one thing they
both improved on was the data connection. FTP was nuts the way it
handles data connections, and active vs. passive has been the source of
much confusion over the years.
(And the source of some teeth gnashing with this project, and the FTP
client that I did.)
How are your DOS programming skills? :-)
Mike
9:19 p.m.
I haven't looked much at HTTP, and I know almost
nothing about Gopher.
(I have some reading to do - I am a U of M grad!) But one thing they
both improved on was the data connection. FTP was nuts the way it
handles data connections, and active vs. passive has been the source of
much confusion over the years.
Yes, for simple downloads FTP is big overkill. For Gopher, the relevant
RFC is 1436, but there are much simpler examples (see Wikipedia's entry).
How are your DOS programming skills? :-)
I have very scant knowledge of x86 assembly (I am much more at home with
6502 and POWER) but I would be delighted to consult at a middle level. :)
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Work harder! Millions on welfare depend on you! ----------------------------
5111
days inactive
5111
days old
5 comments
2 participants
participants (2)
-
mbbrutman-cctalk＠brutman.com -
spectre＠floodgap.com