Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!rutgers!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!umich!abaa!korsberg From: korsberg@abaa.uucp (Ed Korsberg) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Keywords: Transports UDP TCP Performance Message-ID: <5614@abaa.UUCP> Date: 14 Sep 90 11:23:25 GMT References: <1990Sep5.194621.11656@athena.mit.edu> <1990Sep7.153710@apollo.HP.COM> <142133@sun.Eng.Sun.COM> <1990Sep11.131429@apollo.HP.COM> <142319@sun.Eng.Sun.COM> Reply-To: korsberg@abaa.UUCP (Ed Korsberg) Organization: Allen Bradley Lines: 30 In article <142319@sun.Eng.Sun.COM> vipin@samsun.Sun.COM (Vipin Samar) writes: > >O.K., so you did build the entire TCP layer on top of UDP and >you added all the code for that in the NCS library. Has that step really >solved all the problems or perhaps has just moved the problems from one >place to another. > >Another problem with NCS approach is that the user cannot take advantages >out of any of the new performance improvements of any of the transports. >They will have to wait for the NCS team to hack those same fixes into their >software. In ONC, they need not do anything. > I am just joining this discussion so please excuse my innocence on some issues that may have be resolved before. It seems to me that implementing TCP functions in a layer 7 application or ROSE or RPC function is a duplication of effort. TCP (and TP4) has been in developement for years and should be fairly stable from one implementation to another. With this stability people should be able to replace existing software based TCP (or TP4) implementations with either better software solutions or hopefully silicon assisted solutions. In other words why recreate the wheel? Reuse what already is in place and works. -------------------------------------------------------------------------------- -- Ed Korsberg E-mail: korsberg@aa.ab.com Allen Bradley Inc. phone: 313-998-2470 555 Briarwood Circle Ann Arbor, Mich 48104