QNET Proxy idea

bridged with qdn.public.qnxrtp.advocacy
Post Reply
Robert Krten

QNET Proxy idea

Post by Robert Krten » Wed Sep 25, 2002 1:01 pm

One thing that occured to me in the flame-war :-) was that it
might be possible to reduce the QNET traffic to 1/2 for pathname
resolution using a QNX proxy idea.

Let me give some background, and then my proposal. I'm not
claiming that this is a "revelation", and indeed it may have
been presented internally and then abandoned. If so, perhaps
QSSL would be kind enough to share their reasoning with us?

Background:
Opening a file across QNET involves the following transactions:
1) client open()s a name, sending a message to local proc
2) local proc sends redirect to local qnet
3) client sends message to local qnet
4) local qnet sends redirect to remote proc
5) client sends message to remote proc OVER QNET
6) remote proc sends redirect to client OVER QNET
7) client sends message to remote server OVER QNET
8) remote server replies OVER QNET

I'm thinking that it might be possible to reduce steps 4-8 as
follows:
4) local qnet sends "resolution proxy" to remote qnet OVER QNET
5) remote qnet fully resolves the name and sends open() to remote server
6) remote qnet sends file descriptor to local client OVER QNET

This eliminates one of the lookups "over the network" to resolve
the name. It wins even more if there are multiple redirects on
the remote node.

Of course, the main trick will be to use the file descriptor that
the client has to QNET as the "actual" file descriptor for communications
with the remote, instead of as a temporary.

Anyway, just a thought... Please feel free to shoot it down as
appropriate :-)

Cheers,
-RK

--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Kevin Stallard

Re: QNET Proxy idea

Post by Kevin Stallard » Wed Sep 25, 2002 7:09 pm

If I understand this correctly, the extra qnet traffic occurs when something
is opened. For clients that will be participating in IPC with some server
over the long term...the savings probably isn't worth it as the client would
usually only open a connection to a server just once.....however, for
copying files this could speed things up a bit. Interesting.

Kevin



"Robert Krten" <nospam83@parse.com> wrote in message
news:amsc3l$ses$1@inn.qnx.com...
One thing that occured to me in the flame-war :-) was that it
might be possible to reduce the QNET traffic to 1/2 for pathname
resolution using a QNX proxy idea.

Let me give some background, and then my proposal. I'm not
claiming that this is a "revelation", and indeed it may have
been presented internally and then abandoned. If so, perhaps
QSSL would be kind enough to share their reasoning with us?

Background:
Opening a file across QNET involves the following transactions:
1) client open()s a name, sending a message to local proc
2) local proc sends redirect to local qnet
3) client sends message to local qnet
4) local qnet sends redirect to remote proc
5) client sends message to remote proc OVER QNET
6) remote proc sends redirect to client OVER QNET
7) client sends message to remote server OVER QNET
8) remote server replies OVER QNET

I'm thinking that it might be possible to reduce steps 4-8 as
follows:
4) local qnet sends "resolution proxy" to remote qnet OVER QNET
5) remote qnet fully resolves the name and sends open() to remote server
6) remote qnet sends file descriptor to local client OVER QNET

This eliminates one of the lookups "over the network" to resolve
the name. It wins even more if there are multiple redirects on
the remote node.

Of course, the main trick will be to use the file descriptor that
the client has to QNET as the "actual" file descriptor for communications
with the remote, instead of as a temporary.

Anyway, just a thought... Please feel free to shoot it down as
appropriate :-)

Cheers,
-RK

--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Xiaodan Tang

Re: QNET Proxy idea

Post by Xiaodan Tang » Wed Sep 25, 2002 8:36 pm

Kevin Stallard <kevin@ffflyingrobots.com> wrote:
If I understand this correctly, the extra qnet traffic occurs when something
is opened. For clients that will be participating in IPC with some server
over the long term...the savings probably isn't worth it as the client would
usually only open a connection to a server just once.....however, for
copying files this could speed things up a bit. Interesting.
It depends.

If you run a "make" and sources/headers/compilers/libs are on remote,
you endup with LOTS OF OPEN.

If you have all your file system pull over QNET (like we do in QNX4,
one file server for every body in R&D, no local harddisk), you endup
MORE OPEN :)

Yes, the design idea is "OPEN is expensive, but we only do it once".
This is true in an Embedded system, but not general "desktop"
environment.

And Rob, I *think* what you suggested is "doable". It is tricky,
and also the question of is it worth in general case...

-xtang
"Robert Krten" <nospam83@parse.com> wrote in message
news:amsc3l$ses$1@inn.qnx.com...

One thing that occured to me in the flame-war :-) was that it
might be possible to reduce the QNET traffic to 1/2 for pathname
resolution using a QNX proxy idea.

Let me give some background, and then my proposal. I'm not
claiming that this is a "revelation", and indeed it may have
been presented internally and then abandoned. If so, perhaps
QSSL would be kind enough to share their reasoning with us?

Background:
Opening a file across QNET involves the following transactions:
1) client open()s a name, sending a message to local proc
2) local proc sends redirect to local qnet
3) client sends message to local qnet
4) local qnet sends redirect to remote proc
5) client sends message to remote proc OVER QNET
6) remote proc sends redirect to client OVER QNET
7) client sends message to remote server OVER QNET
8) remote server replies OVER QNET

I'm thinking that it might be possible to reduce steps 4-8 as
follows:
4) local qnet sends "resolution proxy" to remote qnet OVER QNET
5) remote qnet fully resolves the name and sends open() to remote server
6) remote qnet sends file descriptor to local client OVER QNET

This eliminates one of the lookups "over the network" to resolve
the name. It wins even more if there are multiple redirects on
the remote node.

Of course, the main trick will be to use the file descriptor that
the client has to QNET as the "actual" file descriptor for communications
with the remote, instead of as a temporary.

Anyway, just a thought... Please feel free to shoot it down as
appropriate :-)

Cheers,
-RK

--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Post Reply

Return to “qdn.public.qnxrtp.advocacy”