Re: More VSTa info?

[yhcrana <dd002b@uhura.cc.rochester.edu> writes:]

>I may be misunderstanding what follows, but would it not be very easy to
>integrate Networking so that it was completely transparent? when the name
>server returns a port, it would somehow indicate that that port was
>somewhere else.

Yes, I had pondered something like that. Alternatively, since the name
lookup is in the C library, it would be easy enough to have open() and
friends understand, for instance, node::path format.

>using VM you could then use a copy-on-read scheme. this
>would only be efficient for LAN set-ups, which may be why you are not
>following that tact. Still, this would allow for vsta to be used on a
>message-passing, multi-processor, while at present it could only take
>advantage of a shared-memory multi-processor (this is what i have gathered
>from perusing the code and your comments...)

Yes, because VM granularity is 4K on the i486, and generally at least as
large on other 32-bit processors, the granularity for message data is too
large. I think I would much rather use message passing hardware in
non-shared architectures as a very fast inter-node networking facility
rather than a local node kernel messaging facility.

>> Machine1
>> USER Client1 TCP/IP Ether-> (to other machine)
>> -------------------V-------^-V----^---
>> KERNEL (Messaging only)
>what are the advantages of this set-up?

All your fancy code is out in user tasks. It can be debugged, unloaded,
replaced, and so forth. With a little C library hackery, it can easily be
made transparent even if it doesn't happen to reside in the kernel.

                                                Andy
Received on Mon Aug 8 14:50:24 1994