monkey@unixprt.UUCP (Monkey Face@unixprt) (12/01/86)
I hope that this is the correct place to post this. Has anyone else noticed that the RFS code in System V Release 3.0 connects to the TLI interface using Connection Oriented Transport Services (COTS), but it expects a message based interface? Since COTS is not a message based interface, unless your transport provider is message based (transparent to TLI) then RFS does not work when activity gets high enough to cause the COTS stream to void a 'message like' look. Protocols like TCP/IP which are also stream oriented can not be used if what I am assuming is true (and I think it is). Earlier version of the V.3 alpha/beta tapes included a thing called NPACK that was between TLI and the transport provider to solve this problem, but is is not in the release. And also, in reality the tranport provider in these cases (when TCP/IP was desired) was really NPACK/TCP/IP. Therefore only interfacing to systems that have an NPACK/TCP/IP transport provider. I have a fix to the RFS code that will allow a true interface to a COTS transport provider. I would especially like to here from the boys/girls at AT&T. Monkey Face @ unixprt (uni-xperts)
ekrell@ulysses.UUCP (Eduardo Krell) (12/02/86)
I have a 3B2 running System V Release 3.1 with local enhancements (job control,
symbolic links, etc.). RFS runs on top of NPACK on top of EMD (EMD is the
hardware driver for the 3BNET board). TCP/IP runs directly on top of EMD.
We can run RFS on top of TCP/IP, but that is slower than running it on
top of NPACK. It is exactly the same RFS code in both cases.
--
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{ihnp4,seismo,ucbvax}!ulysses!ekrellmonkey@unixprt.UUCP (Monkey Face@unixprt) (12/03/86)
>I have a 3B2 running System V Rel 3.1 with local enhancements (job control, >symbolic links, etc.). RFS runs on top of NPACK on top of EMD (EMD is the >hardware driver for the 3BNET board). TCP/IP runs directly on top of EMD. >We can run RFS on top of TCP/IP, but that is slower than running it on >top of NPACK. It is exactly the same RFS code in both cases. >Eduardo Krell AT&T Bell Laboratories, Murray Hill Yes, but 3.1 does not exist yet in the non-ATT world. I have since found out that that the problem I discussed was fixed in 3.1. When will 3.1 be available to the non-ATT world? Also, NPACK is not in the release, will it ever be? Monkey Face@unixprt (uni-xperts)