Hi,
On Thu, Apr 03, 2008 at 05:52:49PM +0200, Ludovic Courtès wrote:
> <[EMAIL PROTECTED]> writes:
> > Actually, most people will consider it easier to use it from a C program
> > as well: For one, it means that you can use the *same* knowledge for
> > doing stuff on the shell, and for writing C
Hi,
On Thu, Apr 03, 2008 at 02:32:25PM +0200, Lluis wrote:
> Well, I don't know how rpctrace internally works, but I suppose it's
> someting similar to ptrace, which gives information at "use-time",
> while such a filesystem would need some kind of introspection
> mechanism on the destination ser
Hi,
<[EMAIL PROTECTED]> writes:
> Actually, most people will consider it easier to use it from a C program
> as well: For one, it means that you can use the *same* knowledge for
> doing stuff on the shell, and for writing C programs. That's a very
> valuable property IMHO.
Isn't it easier to wri
Lluis <[EMAIL PROTECTED]> writes:
> But as I understand it, rpctrace can only look at ongoing messages
Yes, I was only referring to `rpctrace' because of its ability to map
raw message IDs to RPC signatures, which seemed useful in building
lightweight introspection facilities.
Thanks,
Ludovic.
El Thu, Apr 03, 2008 at 05:16:24PM +0200, Ludovic Courtès ens deleit� amb les
seg�ents paraules:
>> Well, I don't know how rpctrace internally works, but I suppose it's
>> someting similar to ptrace, which gives information at "use-time", while
>> such a filesystem would need some kind of intros
Hi,
On Wed, Apr 02, 2008 at 09:23:20AM +0200, Ludovic Courtès wrote:
> <[EMAIL PROTECTED]> writes:
> > A filesystem based interface is much easier to use for most
> > programmers than generic RPCs.
>
> It's easier to use from a shell, not from a C program.
Actually, most people will consider it
Hi,
Lluis <[EMAIL PROTECTED]> writes:
> Well, I don't know how rpctrace internally works, but I suppose it's
> someting similar to ptrace, which gives information at "use-time", while
> such a filesystem would need some kind of introspection mechanism on the
> destination servers, in order to
El Wed, Apr 02, 2008 at 09:19:12AM +0200, Ludovic Courtès ens deleit� amb les
seg�ents paraules:
> Hi,
>
> Lluis <[EMAIL PROTECTED]> writes:
>
>> I'm just an sneaker in many lists but... does Hurd support introspection?
>> Or has any plan to support it? In that case there could be an introspec
Hi,
<[EMAIL PROTECTED]> writes:
> A filesystem based interface is much easier to use for most programmers
> than generic RPCs.
It's easier to use from a shell, not from a C program.
> In this particular case however I don't see the need for a specialised
> RPC interface -- neither is performanc
Hi,
Lluis <[EMAIL PROTECTED]> writes:
> I'm just an sneaker in many lists but... does Hurd support introspection?
> Or has any plan to support it? In that case there could be an introspection
> translator for supporting such fs constructs (all by free with a single
> translator... after payin
Hi,
On Mon, Mar 31, 2008 at 09:43:25PM -0600, Joshua Stratton wrote:
> LP is a special protocol written by the Plan9 team that is something
> in between TCP and UPD. They wanted a reliable stream but as fast as
> UDP and a few other benefits. They said TCP was too slow.
Interesting. I wonder
Hi,
On Tue, Apr 01, 2008 at 02:55:28PM +0200, Ludovic Courtès wrote:
> "Joshua Stratton" <[EMAIL PROTECTED]> writes:
> Plan 9 does everything through "ctl" files that can be read and
> written to with `cat' and `echo', pretty much like Linux sysfs. The
> downside is that all commands have to be
Hi,
On Tue, Apr 01, 2008 at 05:20:54PM +0200, Richard Braun wrote:
> /dev/net/tcp/123 is OK. /dev/eth0/tcp/321 isn't. As I said, you must
> consider TCP as a global layer, otherwise you will run into name space
> conflict problems. For example, a socket in listen mode on INADDR_ANY
> is bound to
Hi,
On Tue, Apr 01, 2008 at 12:45:13PM +0200, Richard Braun wrote:
> In addition, separating the network and transport layers implies
> several problems. The most obvious one concerns performance. The Mach
> IPC subsystem provides nice virtual copy support, but this facility
> creates an importan
Okay, I understand. I think part of this goes back to a question on the
reason for enumeration on these sockets (tcp0, tcp1, etc.) if they aren't
used directly in the socket interface for the developer. I assumed it was
as a convenience for other programs that were monitoring the network. I
agre
El Tue, Apr 01, 2008 at 02:55:28PM +0200, Ludovic Courtès ens deleit� amb les
seg�ents paraules:
> Hi,
>
> "Joshua Stratton" <[EMAIL PROTECTED]> writes:
>
>> They use an interesting system to control their connections using ASCII
>> strings. For example changing the packet size would be as sim
On Tue, Apr 01, 2008 at 08:07:23AM -0600, Joshua Stratton wrote:
> > It's clearly a mistake to map the directory tree to the protocols stack.
> > The TCP implementation is a global layer, it handles network interfaces
> > internally and must not be bound to any interface (ask yourself how to
> > im
>
>
> > I think this approach would fit nicely into the Hurd's translator
> > architecture. However, I'm not sure if I like the directory structure
> they
> > use. I would think the network interface should be shown like
> >
> > /net/eth0/tcp/2
> >
> > It might be worthwhile--but possible bad sty
Hi,
"Joshua Stratton" <[EMAIL PROTECTED]> writes:
> They use an interesting system to control their connections using ASCII
> strings. For example changing the packet size would be as simple as "2400
>> ctl" would change the packet size to 2400 (some syntax to that effect).
Plan 9 does everyth
On Mon, Mar 31, 2008 at 02:07:26PM -0600, Joshua Stratton wrote:
> If anyone hasn't read up on how Plan9 runs their network stack, they have a
> separate directory of each connection. An example in the paper is shown as
> the following,
>
> # cd /net/tcp/2 <--- this is like the second TCP conne
> > Supposedly all network connections use this interface (TCP, UDP, LP).
>
> What is LP?...
LP is a special protocol written by the Plan9 team that is something in
between TCP and UPD. They wanted a reliable stream but as fast as UDP and a
few other benefits. They said TCP was too slow. I'm
Hi,
On Mon, Mar 31, 2008 at 02:07:26PM -0600, Joshua Stratton wrote:
> If anyone hasn't read up on how Plan9 runs their network stack,
Probably most of us haven't...
> they have a separate directory of each connection. An example in the
> paper is shown as the following,
>
> # cd /net/tcp/2
Hi,
On Mon, Mar 31, 2008 at 10:42:58AM -0600, Joshua Stratton wrote:
> Plan9, from what I've read, tries to abstract the interfaces to look
> the same to the client, which seems a little abstract to me if a
> client is going to control the data structures.
Not sure what you mean here...
> I hea
If anyone hasn't read up on how Plan9 runs their network stack, they have a
separate directory of each connection. An example in the paper is shown as
the following,
# cd /net/tcp/2 <--- this is like the second TCP connection
# ls -l
ctl
data
listen
local
remote
status
They use an interesting
Hey,
I did some reading up on the Plan9 design for their network hierarchy. I
think it's interesting. I wouldn't mind using it just so the layout would
be more commonplace (for those who may have used Plan9). I also like the
access to the interface statistics. Plan9, from what I've read, tries
Hi,
On Sat, Mar 29, 2008 at 05:04:48PM +0100, Carl Fredrik Hammar wrote:
> > /ip/eth0/tcp/ /ip/eth0/udp/ /ip/eth1/tcp/ /ip/eth1/udp/ /ip/lo/tcp/
> > /ip/lo/udp/ /ip/tcp/ /ip/udp/
[...]
> Shouldn't it be /eth0/ip/tcp/? I.e. with internet protocol is layered
> over ethernet.
Indeed, the more I th
26 matches
Mail list logo
