Laurens,

> Well, you have to worry about HDLC

        That's simple. It's already implemented.

> (and about flow control when you access
> the drives)

        That's even simpler: no data while accessing drives. MSX will do
the job.

> > Some ISPs still do authentication via SLIP. At least, here in
> > Brazil.
> SLIP only? Here in Holland, some providers still send a text authentication
> string for use with SLIP, but all recognize PPP headers once you've sent
> them.

        I don't know very well about it. What I've seen is only
text-authentication servers.
        So, that's arise a question: how you know an ISP authenticates by
text or by PPP? Checking if the first block sent by the ISP is a PPP
packet or text data? If it's PPP, just start the PPP layer or, if it's
text, start the interactive logon?

> If you need to fill in your IP-address yourself, it's a SLIP connection. If
> you don't, it's PPP.

        Yeah. But I don't know ISP that allow you to fill in your IP
address. :)

> [PPP FCS]
> Yes, I know. I have it (it's RFC1662). My implementation of it works and is
> fast (although the explanation was a bit unclear at first). But it's a
> useless error check. There is no error recovery system provided, and
> besides, IP and TCP already provide there own error discovery mechanisms
> which work just as good, so it's a bit double.

        I agree. But it's useful for PPP control packets (LCP, CCP, IPCP,
etc), UDP and ICMP packets. You can gain some speed if you disable the
checksum for TCP packets, but I doubt if it's worth...

> Some very old ones (which haven't been updated for ages). And with the
> current amount of free providers you can quite easily switch to another one,
> so I don't think it's worth the trouble to implement SLIP as well. Support
> for multiple lower-level protocols only makes things slow.

        Make separate stacks for each lower-level protocols, so you don't
"inflate" the code. But you can run only one "stack" (SLIP or PPP or
anything else) each time (you must shutdown one to start another).

> > The PPP protocol I know. I'm just not familiarized with the
> > interaction of a modem and PPP. I'm just not sure how to "talk" with the
> > modem and to know when I start the PPP layer.
> Through HDLC, documented in RFC1662. That's about all of it. HDLC is a bit
> like SLIP, it provides escape-codes to use packets over a serial line.

        Reading other replies I figured out how this interaction is done.
Now I just need to make that &*$%&�$% modem works...

> You still receive 'challenges' after you have connected (in case someone
> 'takes over' your connection... yeah right!). And if you don't answer them,
> you get disconnected. No, PAP is much much much much simpler.

        Bah... Just to make your connection slower...
        Do you know any ISP that accepts only CHAP?

> > > Header Compression
> > It's worth, since this kind of compression is too easy.
> It complicates my implementation, which means it slows down. And I want as
> much speed as possible.

        Strange... In my implementation, it speeds up the connection,
since I know that I can skip that bytes... Maybe my PPP layer is better
implemented than yours? :)

> > Right. I recommend you implementing Van Jacobson compression.
> > That's what I'm doing right now on UZIX.
> I was already thinking about that. What's the RFC of the docs???

        RFC 1144.

> Hmmm... Well I'm not that much of a modem-expert either. But it's quite
> simple, once you understand HDLC.

        Maybe you can answer my last mail about modems, so (the one with a
BASIC code)?


Adriano Camargo Rodrigues da Cunha               ([EMAIL PROTECTED])
Engenharia de Computacao - UNICAMP   
http://www.adrpage.cjb.net           http://if.you.dont.like.msx.usuck.com

* Microsoft Windows... a virus with mouse support. *



****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****

Reply via email to