jim@syteke.be (Jim Sanchez) (02/26/90)
My Company is thinking about trying to support something such as SLIP
on our terminal server ports. With PPP now becoming defined and SLIP
still kinda implementation specific, what does the net think about the
advisability of moving to PPP. Of course, the no-brainer answer would
be to do both but that costs time and money :-). Seriously, if people
have thoughts on this subject, I'd like to hear about it either via
email or posting. I'll summarize the email traffic if I receive any.
Thanks
--
Jim Sanchez {sun,hplabs}!sytek!syteke!jim OR
Hughes LAN Systems, Brussels uunet!prlb2!sunbim!syteke!jimskl@van-bc.UUCP (Samuel Lam) (03/02/90)
In article <765@syteke.be>, jim@syteke.UUCP (Jim Sanchez) wrote: >My Company is thinking about trying to support something such as SLIP >on our terminal server ports. With PPP now becoming defined and SLIP >still kinda implementation specific, what does the net think about the >advisability of moving to PPP. Of course, the no-brainer answer would >be to do both but that costs time and money :-). It's really only half a "no-brainer" answer, depending on which protocol you implement first... If you implemented PPP first, then doing SLIP will only take a tiny little bit more time. However, if you implemented SLIP first, doing PPP will take a *lot* longer. In short, SLIP is small, PPP is huge. If you alreday did PPP, you might as well do SLIP so you can say you have both. But if you have only done SLIP, then doing PPP just so that you can claim you have both is not worth it. There isn't any common code you could use for both SLIP and PPP. So having done one does not give you a head start on the other. My opinion is to do SLIP first (this will buy you time) and then do PPP after that. This way you can talk to existing SLIP entities right away, and by the time your PPP is ready there will hopefully be some other PPP entities around for you to talk to. ...Sam -- Internet: <skl@wimsey.bc.ca> UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl