>Uh... I don't know if I see the relation between your good experiences
>downloading to your PC and the VC/DG discussion. The issue is not a
>matter of bandwidth, or even that of ease of programming (both VC's and
>datagrams are media independent, and as long as you have something
>like libwww, why should one care?)
My argument was that virtual circuit technology is more widely
deployed, presumably because it's easier to "tunnel" VC's inside each
other than to encapsulate datagrams. I think the conclusion that VC's
are more widely deployed holds (I believe the Merit statistics report
that FTP, HTTP, and Gopher constitute over 50% of all packets on the
internet), but I don't know if I have correctly identified the cause.
> In practice,
>once you start a single BIG transfer, since no-one takes care to implement
>load-throttling, you might as well be directly connected through one
>session, because everything else comes to a halt.
This was not my experience. term does some sort of priorities or
something. In any case, I noticed only a small change in the
responsiveness of my mail/news/Mosaic sessions that were concurrent
with my FTP download.
>I say we go ahead and dispense with the VC<->DG debate. I prefer the RPC
>vs. Messaging one. Should libwww just switch to RPC and do away with
>this HTTP protocol business. Anyone? >;-)
Are we using different terminology for the same thing, or am I really
confused about these terms? To my mind, HTTP _is_ an RPC protocol:
the client sends a request, and the server answers. That's why I think
it's overkill to use TCP.
Or by RPC do you mean Sun RCP with their stubgen and all that? Or
would DCE RPC, or ILU RPC do the trick?
Could you elaborate on the distinction between RPC and messaging?
Dan