On Thu, 11 Nov 1999, Vali Dragnuta wrote:
> As I knew about ELKS acute need for networking /* :-) */, here is
> an idea I have to deal with the problem quite in a simple way.
Ideas are fine, but I got sick of people talking about networking and just
wrote it. Writing code is much faster for development than yakking about
it.
> The main impediment in doing that is that it's quite (_very_) hard to
> make a _real_ network terminal (more than telnet or serial terminal)
> with a 640k ram 8086,BECAUSE
> -It-s a laptop so only a parallel net adaptor could be used.
Does it have a PCMCIA slot? Does it have a serial/parallel port for PPP
or PLIP?
> -Even a for a desktop it would be hard to find a net card to _work_ in
> it.
Not at all. 8086 simply means it's only got an 8bit slot so you get an
8bit card, such as an ne1000 or a wd8003. Over the years, I've found that
quite a few 16 bit cards will work in 8bit slots.
> -If somehow we could deal with theese, the BIGgest problem is the memory
> a IP+TCP+UDP implementation would be _very_ expensive in memory
I dunno about that. My ethernet driver is 3k, which is quite 'expensive',
but is quite possible to shrink it. Remember that the etherboot supports
ethernet, IP, UDP, rarp/bootp and tftp in under 16k, along with quite a
few extras in there too.
> and this does not include my frontend<->backend postgres protocol, and
> does not include the frontend application.
Firstly, the network stuff will be in kernel space, not user space, so
this isn't a problem. However, you'll be pushing it very hard if you can
get your postgres library into a single 64k segment.
> What is this all about:
> We're clear that a full TCP implementation would be expensive.
Read what I just said above about etherboot. While I admit that TCP is a
bit more overhead, it's not impossible.
> Because IP is quite stuffy (quite many options to care about), and
> TCP is even more complex for a 8086 toy.
You don't need to recognize all the options, infact even Big Linux doesn't
recognize them all.
[ SNIP: Information about KISS ]
The big problem I see with KISS is the same problem that happened with
term and socks similar programs. Old protocols are unable to work without
modification and linking against the KISS library. The next question is
would the overhead of the library justify the saving of not having TCP
code in the kernel? I don't think it would.
> Anyway, the main idea is to create a much simpler but safe protocol for
> local low distance communication,and a protocol translator on the real
> linux side.
While this does look good for it's task, I think it looks unusable as a
permanent replacement for full TCP/IP stack.
> So if you find this could be useful for elks, let's discuss about the
> lower level stuff, so that eventually both my msdos kiss tcp and elks
> kiss tcp would be inter-operable.
I wouldn't think there'd be any lower-level stuff at all. At least as far
as ELKS is concerned. As far as an application, you'd need to design the
protocol, but this can all be done over the existing serial driver in
ELKS.
Davey
