Is there any CP/M InterNet Software?
Jay S. Siegel
3½") disk system marketed by Zebra Systems (I helped with the IMP
overlay for this system). I would like to know if there's any
Internet software for CP/M out there & details, if so.
Thanks,
Jay
--
------------------------------------------------------------------------
Posted with Amiga NewsRog
------------------------------------------------------------------------
George Hostler
Someone ported Lynx, a text based, Unix web browser, to DOS some time ago.
There is a link to it on http://www.clones.com/
He ran into a problem with the amount of memory required, that just about
demanded it run on a 386 system. If IMP (and it has been a while since I
used it on my Xerox 16/8, an upgraded 820-II) has VT-100 terminal emulation,
you may be able to dial up your internet provider. Once logged on and
provided he has it (most likely does), type in "lynx" and hit "enter".
Good luck,
George
Jay S. Siegel wrote in message ...
gkl...@seganet.com
On 1999-01-05 ka2...@nospam.nowhere said:
>I have a few Timex/Sinclairs 2068's with the Portuguese 3" (not
>3.5") disk system marketed by Zebra Systems (I helped with the IMP
>overlay for this system). I would like to know if there's any
>Internet software for CP/M out there & details, if so.
Sorry, Jay, there is no 'Net browser software available for CP/M;
nowhere, no-how. And there's never likely to be.
A 'Net browser for CP/M would be extremely problematic. Just one
example: the TCP/IP stack alone would probably take up more memory
than the average CP/M machine possesses.
Your only practical options for accessing Duh 'Net with a CP/M-
based computer are:
1) A SHELL account with a local ISP...if you can find a provider
still offering SHELL accounts.
2) A text-based dial-in service...often available from semi-
Guvvermint entities such as local public libraries.
In either case, you'd use your normal communications software.
=Return address is mangled to deter spam. Remove all "g"s to e-mail.=
Net-Tamer V 1.08X - Test Drive
Bruce McFarling
>
>On 1999-01-05 ka2...@nospam.nowhere said:
>
> >I have a few Timex/Sinclairs 2068's with the Portuguese 3" (not
> >3.5") disk system marketed by Zebra Systems (I helped with the IMP
> >overlay for this system). I would like to know if there's any
> >Internet software for CP/M out there & details, if so.
>
>Sorry, Jay, there is no 'Net browser software available for CP/M;
>nowhere, no-how. And there's never likely to be.
>
>A 'Net browser for CP/M would be extremely problematic. Just one
>example: the TCP/IP stack alone would probably take up more memory
>than the average CP/M machine possesses.
Since the early net was running on machines with less memory
than most CP/M machines, its odd that the *minimum* memory required
for a TCP/IP is so large. Are you sure this is not an optional
increase in packet size for extra performance?
Telnet and ftp alone would be useful for those who can telnet
into a place with a lynx available.
The other way to get around the limitations is by email. I
know that at one time there were www-by-email and ftp-by-email
gatewyas running. That wouldn't be online browsing, but it gives
access to the net to those who are otherwise locked out.
(
----------
Virtually,
Bruce McFarling, Newcastle,
ec...@cc.newcastle.edu.au
)
D. Peschel
Bruce McFarling <ec...@cc.newcastle.edu.au> wrote:
> Since the early net was running on machines with less memory
>than most CP/M machines, its odd that the *minimum* memory required
>for a TCP/IP is so large. Are you sure this is not an optional
>increase in packet size for extra performance?
I don't know much about the history of the 'Net, but I think you're
confusing two kinds of machines. The IMPs (which at one time did all the
gruntwork of sending and receiving packets) may not have had much memory,
but the hosts (which people actually used) did, I would say.
The full address space for a PDP-6 or PDP-10 was 256 kilowords (1 word =
36 bits). People often added extra memory-management hardware so they could
have more memory. As for UNIX, the first version may have made do with 64K
but I'm sure the requirements grew by the time BSD and the 7th Edition
arrived! I would call these typical configurations for networked machines.
Also, I know the protocols changed several times and there may have been
other hardware working behind the scenes.
Basically, I'm skeptical that 64K (with CP/M taking up 8) is enough for any
kind of modern Internet application.
-- Derek
Bruce McFarling
wrote:
>I don't know much about the history of the 'Net, but I think you're
>confusing two kinds of machines. The IMPs (which at one time did all the
>gruntwork of sending and receiving packets) may not have had much memory,
>but the hosts (which people actually used) did, I would say.
>The full address space for a PDP-6 or PDP-10 was 256 kilowords (1 word =
>36 bits). People often added extra memory-management hardware so they could
>have more memory. As for UNIX, the first version may have made do with 64K
>but I'm sure the requirements grew by the time BSD and the 7th Edition
>arrived! I would call these typical configurations for networked machines.
>Also, I know the protocols changed several times and there may have been
>other hardware working behind the scenes.
>Basically, I'm skeptical that 64K (with CP/M taking up 8) is enough for any
>kind of modern Internet application.
Your shifting the yardsticks. The question was whether it was
possible to get connected to the net with a CP/M computer. Now, since
there is a demo of a Commodore 64 with a telnet connection over slip,
I'm skeptical about the `impossible' reaction. Rephrase the question
to ``a modern Internet application'' (which, after all, may well have
been the original intent) and the ``impossible'' is a bit more
plausible. Netscape? no. Streaming audio? I don't *think* so.
If the question is, has it been implemented, which is an even
more plausible reading of the question, the answer is probably not.
But bear in mind the time horizon for a lot of serious CP/M
development. I'd like to hear if it has been done, but I'm not holding
my breath.
What my post addressed wasn't what can't be done but what can
be. Telnet and ftp aren't exactly Netscape. The question isn't what
can't be done, but what can. A connection needs a buffer, and bigger
buffers up to a point can give better performance. And that's a
multiplicitive relationship. If you trim connections supported by 50%
and buffer size by 40%, the end result is 30% as much memory allocated
in that area. If you trim buffer size by 80%, the end result is 10% as
much memory allocated in that area. And there's the Commodore 64
example, which is for a stock Commodore 64, which, last I had one (a
while ago) right around 64K RAM, total.
kgl...@seagnet.com
On 1999-01-06 ec...@cc.newcastle.edu.au(BruceMcFarling) said:
> > A 'Net browser for CP/M would be extremely problematic. Just one
> > example: the TCP/IP stack alone would probably take up more memory
> > than the average CP/M machine possesses.
>
>Since the early net was running on machines with less memory
>than most CP/M machines, its odd that the *minimum* memory required
>for a TCP/IP is so large. Are you sure this is not an optional
>increase in packet size for extra performance?
The early 'Net (Internet, that is) wasn't running on machines with less
memory than most CP/M machines. It was usually running on mainframes as
servers...and it was the =servers= that were handling all the protocols and
packets between sites. Any small, low-memory desktop machine that might
have been connected to a server was merely, in essence, playing the role
of a dumb terminal. It didn't have to handle protocols and packets; it
only handled console, and occasionally disk, I/O. Doesn't take much memory
to do THAT.
Sure, there were different protocols and packet sizes is use. But today,
commercial Internet Service Providers mostly require that the calling
machine use Point-to-Point Protocol (PPP)...which means a supporting TCP/IP
on the caller's end. That's why you'll likely never see 'Net software
for CP/M-80.
Now =CP/M-86= is a different story. CP/M-86 running on an IBM clone is
eminently suited for a full-blown 'Net access program with TCP/IP. D'ya
s'pose we could persuade David Colston to port NET-TAMER to CP/M-86? <g>
>Telnet and ftp alone would be useful for those who can telnet
>into a place with a lynx available.
Well, if a dial-in UNIX-based server is accessible, than all problems are
solved, anyway. If LYNX is available there, one should (theoretically) be
able to access FTP, since FTP is supported by LYNX. However, many of the
quasi-public organizations providing dial-in 'Net access in the U.S.A.
disable LYNX's FTP function.
But even without LYNX, if one can connect to a 'Net server at the UNIX
command or pseudo-command level (a SHELL account), then ALL 'Net functions
should be available simply by manually issuing the proper UNIX commands.
>The other way to get around the limitations is by email. I
>know that at one time there were www-by-email and ftp-by-email
>gateways running. That wouldn't be online browsing, but it gives
>access to the net to those who are otherwise locked out.
Possible, but very cumbersome. Doubtful that today's instant-gratification
generation would put up with it.
Have a middy o'fifty for me, mate. Wait...on second thought, make that
a brandy and dry. With pie'n'peas. Aahhh, I miss those pub lunches. :)
Bruce McFarling
>Sure, there were different protocols and packet sizes is use. But today,
>commercial Internet Service Providers mostly require that the calling
>machine use Point-to-Point Protocol (PPP)...which means a supporting TCP/IP
>on the caller's end. That's why you'll likely never see 'Net software
>for CP/M-80.
OK, that's the question. How much more demanding is PPP than
SLIP in terms of memory requirements, since SLIP has been implemented
for 64K RAM systems.
>Well, if a dial-in UNIX-based server is accessible, than all problems are
>solved, anyway.
Yeah, but for those that don't have it, it's getting rare in
some parts. Here's a trick that occasionally works, for systems that
have a
user:
password:
local>
style login to the ppp server. Try telnet and see if its on. If it is,
a VT100 compatible terminal and your off.
...
>But even without LYNX, if one can connect to a 'Net server at the UNIX
>command or pseudo-command level (a SHELL account), then ALL 'Net functions
>should be available simply by manually issuing the proper UNIX commands.
Again, fine if you have it, worth a look to see. I did a good
amount of usenet news browsing earlier in the decade with a
hand-me-down Kaypro running a VT-52 terminal emulator (might have been
kermit) onto a university shell account, while my hand-me-down 286 was
bogged down in long debugging runs.
Ah, student days. Used to be I had time but no money. Now I
have neither. (BTW, go vols).
> >The other way to get around the limitations is by email. I
> >know that at one time there were www-by-email and ftp-by-email
> >gateways running. That wouldn't be online browsing, but it gives
> >access to the net to those who are otherwise locked out.
>
>Possible, but very cumbersome. Doubtful that today's instant-gratification
>generation would put up with it.
I think what keeps gateways like that online is the fact that
the instant gratification generation *doesn't* use them. Otherwise
they'd be swamped and close down.
I don't think they work for streaming audio anyway.
>Have a middy o'fifty for me, mate. Wait...on second thought, make that
>a brandy and dry. With pie'n'peas. Aahhh, I miss those pub lunches. :)
Say what? What y'all goin on about, now? Why in the hell
wouldn't I get a schooner with such good beer on tap.
lis...@zetnet.co.uk
On 1999-01-06 ec...@cc.newcastle.edu.au(BruceMcFarling) said:
:OK, that's the question. How much more demanding is PPP than
:SLIP in terms of memory requirements, since SLIP has been
:implemented for 64K RAM systems.
Hmm. About 5 times, given the relative sizes of the DOS programs I have
(not that this is necessarily accurate) - relative sizes 8k vs 40-50k. On
the other hand, most of the connections I've seen will suck on SLIP equally
happily.
:>Have a middy o'fifty for me, mate. Wait...on second thought, make
:>that a brandy and dry. With pie'n'peas. Aahhh, I miss those pub
:>lunches. :)
:Say what? What y'all goin on about, now? Why in the hell
:wouldn't I get a schooner with such good beer on tap.
Erm. Klaw thinks you're Australian, from the email address. He does this
every so often. Best to humour him. <gd&r>
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
lis...@zetnet.co.uk
On 1999-01-06 kgl...@seagnet.com said:
:Now =CP/M-86= is a different story. CP/M-86 running on an IBM
:clone is eminently suited for a full-blown 'Net access program with
:TCP/IP. D'ya s'pose we could persuade David Colston to port
:NET-TAMER to CP/M-86? <g>
You could try, but a better approach might be to port KA9Q to CP/M-86. As I
recall, the source is freely available, and plenty of people have
experience hacking it. All you'd need is a decent C compiler. Net-Tamer is
proprietary, which is a bit of a problem - the only one with the source is
David Coulston, and a lot depends on what he's prepared to do with it.
lis...@zetnet.co.uk
On 1999-01-06 ec...@cc.newcastle.edu.au(BruceMcFarling) said:
:Since the early net was running on machines with less memory
:than most CP/M machines, its odd that the *minimum* memory required
:for a TCP/IP is so large. Are you sure this is not an optional
:increase in packet size for extra performance?
As I recall, TCP/IP was developed atop a load of PDP-10s. I refuse to
believe that any were ever shipped with under 256Kw (of 36-bit memory, so
1152Kb) as standard (ie. their full address space; 2 addresses per word).
Maybe people got TCP/IP running on PDP-11s later, but I don't think TCP
arrived for Unix until BSD - and wasn't that 32-bit from the start?
I dare say you could pack a TCP/IP into under 64k; the problem comes with
running stuff on top of it. You need a hell of a lot of disk space to
download your average newsfeed and mailbox - would a couple of floppies be
up to it? You could always read mail (with POP3) and news online, using a
local feed, and certainly you could download web pages and ftp stuff for
consumption later. But then you start fighting for space.
Still, if you can do it, Forth would be the way to go, I guess... ;>
lis...@zetnet.co.uk
On 1999-01-06 dpes...@u.washington.edu(D.Peschel) said:
:hardware so they could have more memory. As for UNIX, the first
:version may have made do with 64K but I'm sure the requirements
:grew by the time BSD and the 7th Edition arrived! I would call
:these typical configurations for networked machines.
No, Version 7 is fine with the kernel inside 64k. A number of clones,
including one for a Z80, have proved the point. However, I'm pretty sure
that v7 didn't have TCP/IP.
(It's also worth noting that sockets may not be the appropriate paradigm in
a block-based filing system with a RAM shortage.)
Bruce McFarling
>I dare say you could pack a TCP/IP into under 64k; the problem comes with
>running stuff on top of it. You need a hell of a lot of disk space to
>download your average newsfeed and mailbox - would a couple of floppies be
>up to it? You could always read mail (with POP3) and news online, using a
>local feed, and certainly you could download web pages and ftp stuff for
>consumption later. But then you start fighting for space.
Gosh. What would be the first priorities if space was tight?
Well, telnet could get you to somewhere else on the net that could
give you lynx, so that would be a good thing. Of course, you'd need
ftp to download files and stuff. Read news online.
The original notion here was to hold onto the dial-up terminal
connection as dial up terminal connections get harder to find,
replaced by PPP connections. If PPP need 5 times the space as SLIP, it
ought to fit in 64K fine, with at least a little room to spare. Of
course, running light, without overbyte.
lis...@zetnet.co.uk
On 1999-01-12 ec...@cc.newcastle.edu.au(BruceMcFarling) said:
:On 10 Jan 1999 22:23:20 GMT, lis...@zetnet.co.uk wrote:
:>I dare say you could pack a TCP/IP into under 64k; the problem
:>comes with running stuff on top of it. You need a hell of a lot of
:>disk space to download your average newsfeed and mailbox - would a
:>couple of floppies be up to it? You could always read mail (with
:>POP3) and news online, using a local feed, and certainly you could
:>download web pages and ftp stuff for consumption later. But then
:>you start fighting for space.
:Gosh. What would be the first priorities if space was tight?
:Well, telnet could get you to somewhere else on the net that could
:give you lynx, so that would be a good thing. Of course, you'd need
:ftp to download files and stuff. Read news online.
Telnet is the absolute top priority; with telnet and a capture program you
can get POP3, SMTP and (possibly) NNTP and HTTP, if you're prepared to
learn the protocols. I don't know about FTP. Don't try to use a fast modem,
and turn off compression if you can. (Make life easier on your disk
drive...)
:The original notion here was to hold onto the dial-up terminal
:connection as dial up terminal connections get harder to find,
:replaced by PPP connections. If PPP need 5 times the space as SLIP,
:it ought to fit in 64K fine, with at least a little room to spare.
:Of course, running light, without overbyte.
But PPP doesn't give you a TCP/IP stack; that's extra. To get telnet going
on CP/M, I would try like hell to use SLIP, and find an ISP that still
supports it (most should, but there's a spate of freebies starting up in
this country and they almost certainly won't).
Another approach may be to download Twinsock onto a Windoze pute, study the
source (I believe it comes with source) and then write something similar
that will work on your CP/M box. There should be room for a TCP-Lite kind
of protocol, exactly for small computers and slow modems, without the
full generality of TCP/IP. (It used to be called a shell account... *sigh*)
For example, for donwloading news and mail, my ISP gives you the option of
using either straight TCP with the overlaid SMTP/POP3/NNTP protocols, or
using a protocol called ZIMACS which is based on Z-modem. Unfortunately
ZIMACS is proprietary and they only seem to have Windows programs to handle
it, but there are distinct possibilities there. In fact, if you can
regularly get much higher speeds out of it than regular TCP could manage,
and then make it transparent to the user (ie. do what Twinsock did and
implement a Winsock-alike interface to it), you could have the makings of a
new standard... ;>
Bruce McFarling
>But PPP doesn't give you a TCP/IP stack; that's extra. To get telnet going
>on CP/M, I would try like hell to use SLIP, and find an ISP that still
>supports it (most should, but there's a spate of freebies starting up in
>this country and they almost certainly won't).
I've just had a glance over the RFC for PPP, and it looks like
a stripped down PPP ought to be real easy. PPP has an option
negotiation session. Much of the bulk of PPP drivers seems to be
support for optional features. A PPP driver dedicated to the support
of TCP/IP, for example, can simply refuse Apple Talk, packet
compression, and a collection of other options, by hardwiring the
options that it recognises and can accomodate, and returning a NAK
packet for all other requests.
The other interesting thing was the packet size.
Conservatively, you `have' to be able to support a maximum IP packet
size of around 576 bytes for incoming packets. But if the maximum
packet size announcement is respected, you can request bigger ... *or
smaller*. Of course, the overhead gets higher: maximum IP and FTP
protocal overhead can be 160 bytes, minimum 40 bytes, so the smaller
the packet, the more lost to headers. And there is no minimum packet
size: each packet says how long it is. So a system that wanted to work
with 256 byte sized packets could do so, if it was willing to gamble
on not meeting a sender that ignored the maximum packet size
announcement.
An additional advantage of a small maximum packet size
announcement is that fragment reassembly occurs when a big packet is
sent through a link that doesn't support packets of that size. A
maximum packet size of 576 or less should mean no fragments to
reassemble.
If I did it, I'd have to do it in Forth, since I'm not working
in C anymore and my assembly language skills are on another small
processor. If I can work out ANS file-words for Camel Forth, I'll look
into it for sometime after summer is over. Maybe toward the winter
break between terms in July.
Jay Siegel
BM> >Sorry, Jay, there is no 'Net browser software available for
BM> >CP/M; nowhere, no-how. And there's never likely to be.
BM> >
BM> >A 'Net browser for CP/M would be extremely problematic. Just
BM> >one
BM> >example: the TCP/IP stack alone would probably take up more
BM> >example: memory
BM> >than the average CP/M machine possesses.
What about bank-switched CP/M Plus systems, as well as Z3 Plus
systems? Also, a Z180 can directly address 1 meg, I believe as well
as the Z280 addressing even more. Will your TCP/IP stack that you're
planning to write allow for this additional memory in some sort of
"Installation" procedure?
>
BM> Since the early net was running on machines with less memory
BM> than most CP/M machines, its odd that the *minimum* memory
BM> required for a TCP/IP is so large. Are you sure this is not an
BM> optional increase in packet size for extra performance?
BM>
BM> Telnet and ftp alone would be useful for those who can telnet
BM> into a place with a lynx available.
BM>
BM> The other way to get around the limitations is by email. I
BM> know that at one time there were www-by-email and ftp-by-email
BM> gatewyas running. That wouldn't be online browsing, but it gives
BM> access to the net to those who are otherwise locked out.
If I can add my 2¢ to what clients I'd like to see.
1) A TCP/IP stack that can haandle PPP (Obviously) 2) Telnet
3) FTP
4) Finger
5) e-Mail
Let me just add that e-mail can be buffered onto a disk or disks,
much like the virtual RAM concept. Those with hard disk systems
should have no problem with this. Those systems that only have
floppy disk(s), are obviously limited, but I'd like to see floppy
disks from a: to P: avaliable for usage, with an option to limit
it to less, if so desired.
6) Net News reader with buffering as described in #5 above, for
e-mail. 7) A text-only "browser" with buffering as described in #5
above, for e-mail.
5,6,& 7 would obiously take a little more though than the first 4. ;)
Jay
--
------------------------------------------------------------------------
Posted with Amiga NewsRog (Amiga News client),
Hardware: NTSC Amiga A1200 with phase 5 1260 68060 accelerator card &
Fast SCSI-2 daughter card, SuperGen SX genlock & DCTV with
RGB converter (for video work), Jaz Drive & CD-ROM changer,
NTSC A2000 with the NewTek Video Toaster, & NTSC A4000.
Internet Software: Miami 3.2 (TCP/IP stack), YAM p2r5 (e-mail client),
AmIRC 2.2 (IRC client), strICQ (ICQ client), Termite FTP
(FTP client), Termite Telnet (Telnet client), mFinger (Finger
client), IBrowse ver 1.22 (Web Browser), & AmigaOS ver. 3.1
In a world without walls & fences, who needs Windows & Gates?
------------------------------------------------------------------------
Shawn Sijnstra
It shouldn't be too hard. All it takes is time (that nobody has)
and effort (I'm a tad lazy myself). If enough people actually start
coding, it will get done. All we need is someone to start the ball
rolling. There was someone a while back who had done it on the z80
for a standalone box and was offering to convert it to CP/M if there
was enough interest, but there probably wasn't.
Jay Siegel wrote:
>
> "BM" == "Bruce McFarling" writes:
>
> BM> >Sorry, Jay, there is no 'Net browser software available for
> BM> >CP/M; nowhere, no-how. And there's never likely to be.
> BM> >
> BM> >A 'Net browser for CP/M would be extremely problematic. Just
> BM> >one
> BM> >example: the TCP/IP stack alone would probably take up more
> BM> >example: memory
> BM> >than the average CP/M machine possesses.
Ummm no. It's been done on a commodore64. All you do is only
accept packets in order, and send reject to all other packets. That
way you only need a buffer big enough for one packet. (The C64
effort was done using SLIP, but PPP isn't much bigger).
>
> What about bank-switched CP/M Plus systems, as well as Z3 Plus
> systems? Also, a Z180 can directly address 1 meg, I believe as well
> as the Z280 addressing even more. Will your TCP/IP stack that you're
> planning to write allow for this additional memory in some sort of
> "Installation" procedure?
>
Tricky.... each hardware setup will be different.
> If I can add my 2¢ to what clients I'd like to see.
>
> 1) A TCP/IP stack that can haandle PPP (Obviously) 2) Telnet
> 3) FTP
> 4) Finger
> 5) e-Mail
> 6) Net News reader with buffering as described in #5 above, for
> e-mail. 7) A text-only "browser" with buffering as described in #5
> above, for e-mail.
>
> 5,6,& 7 would obiously take a little more though than the first 4. ;)
>
> Jay
> --
Well, with a large RAM drive this should be doabe, but 2-4 should be
so easy it's not funny. Same goes for ping and traceroute.
Cheers,
Shawn
Shawn Sijnstra
It shouldn't be too hard. All it takes is time (that nobody has)
and effort (I'm a tad lazy myself). If enough people actually start
coding, it will get done. All we need is someone to start the ball
rolling. There was someone a while back who had done it on the z80
for a standalone box and was offering to convert it to CP/M if there
was enough interest, but there probably wasn't.
Jay Siegel wrote:
>
> "BM" == "Bruce McFarling" writes:
>
> BM> >Sorry, Jay, there is no 'Net browser software available for
> BM> >CP/M; nowhere, no-how. And there's never likely to be.
> BM> >
> BM> >A 'Net browser for CP/M would be extremely problematic. Just
> BM> >one
> BM> >example: the TCP/IP stack alone would probably take up more
> BM> >example: memory
> BM> >than the average CP/M machine possesses.
Ummm no. It's been done on a commodore64. All you do is only
accept packets in order, and send reject to all other packets. That
way you only need a buffer big enough for one packet. (The C64
effort was done using SLIP, but PPP isn't much bigger). Well, not the
web browser, but telnet & ping.
>
> What about bank-switched CP/M Plus systems, as well as Z3 Plus
> systems? Also, a Z180 can directly address 1 meg, I believe as well
> as the Z280 addressing even more. Will your TCP/IP stack that you're
> planning to write allow for this additional memory in some sort of
> "Installation" procedure?
>
Tricky.... each hardware setup will be different. You'd have to reserve
memory somehow.
Jonathan Graham Harston
> I (as others) have also been wanting to write TCP/IP for CP/M.
I've been trying to do this for some time, but the hardest part
has been just getting hold of documentation to tell me what and
how to implement it. Everything I track down say things like
'TCP/IP wraps packets in other packets with headers, etc...'.
Yes, I know that, but what are the actual bytes and stuff that you
actually have to send and receieve????
Nothing I've found goes anywhere further that cutesy little diagrams
of packet encapsulation concepts.
--
Jonathan Harston <j...@arcade.demon.co.uk>
Office IT Administrator
Focus Editor for Walkley Ward
Sheffield Liberal Democrats
Tim Mann
Jonathan Graham Harston <j...@arcade.demon.co.uk> wrote:
>Shawn Sijnstra wrote:
>> I (as others) have also been wanting to write TCP/IP for CP/M.
>
>I've been trying to do this for some time, but the hardest part
>has been just getting hold of documentation to tell me what and
>how to implement it.
The standards for TCP, IP, and other Internet protocols are written up
in a series of documents called "RFCs". You can find them all at
http://www.faqs.org/rfcs/index.html (and many many other places).
These documents go into complete detail about where every last bit and
byte needs to go.
Check the page http://www.faqs.org/rfcs/std/std-index.html for RFCs
that have been made into Internet standards. These have recently been
given numbers in the new STD series, saving you from having to wade
through the complete list of almost 2500 RFC documents to find which
ones are relevant. You will probably want to skim a little of STD0001
(Internet Official Protocol Standards) for background, then dig into
STD0003 (Host Requirements) and the other major documents that it
references, like 0005 (IP), 0006 (UDP), 0007 (TCP), 0008 (Telnet),
0009 (FTP), maybe 0013 (Domain Name System), and either 0047 (SLIP) or
0051 (PPP). If you actually implement Telnet you'll need some of the
documents on Telnet options, too, but I won't list those here.
Trivia item: you'll find my name somewhere on the std-index page. You
almost certainly don't need to read the minor STD that it's attached
to, though. :-)
--Tim
--
Tim Mann <ma...@pa.dec.com>, Compaq Systems Research Center
http://www.research.digital.com/SRC/personal/Tim_Mann/
pete$...@pdlmail.demon.co.uk
j...@arcade.demon.co.uk "Jonathan Graham Harston" writes:
> Shawn Sijnstra wrote:
> > I (as others) have also been wanting to write TCP/IP for CP/M.
>
> I've been trying to do this for some time, but the hardest part
> has been just getting hold of documentation to tell me what and
> how to implement it. Everything I track down say things like
> 'TCP/IP wraps packets in other packets with headers, etc...'.
>
> Yes, I know that, but what are the actual bytes and stuff that you
> actually have to send and receieve????
>
> Nothing I've found goes anywhere further that cutesy little diagrams
> of packet encapsulation concepts.
If you're happy to spend some time going through lots of C
source and headers, you could find the detail you want in a
working port of Phil Karn's NOS (ka9q) - get it by anonymous
ftp from:
ftp://ftp.demon.co.uk/pub/demon/ibmpc/dos/files/source/ka9q216d.zip
Agreed this is for the PC (8088/8086), but I doubt that the
ASM bits will be of interest anyway. About 700K IIRC. And
it does work - I'm posting this with it :-)
--
Pete
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
Richard Kanarek
Now who would be happy doing something like that?
Cordially,
Richard Kanarek
Also cross about the (apparent) lack of a WELL written BOOK on all
things Internet'ing.
ken brakey
Richard Kanarek wrote:
> pete$no$p...@pdlmail.demon.co.uk wrote:
> > If you're happy to spend some time going through lots of C
> > source and headers,...
>
> Now who would be happy doing something like that?
no problem use grep. you can search (if you have time) for one word in
every file on your disk. GREAT utility, learn to use it!
>
>
> Cordially,
> Richard Kanarek
>
> Also cross about the (apparent) lack of a WELL written BOOK on all
> things Internet'ing.
here is a URL that has everything you want to find out that I can't
recall right now. I downloaded some stuff the other day on tcp/ip. Do
a search on tcp/ip standard that's where I found it.
ken