QNET Proxy idea

QNX Newsgroups (Archives) qdn.public.qnxrtp.advocacy
1

One thing that occured to me in the flame-war :slight_smile: 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
    :sunglasses: 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 :slight_smile:

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.

2

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 > :slight_smile: > 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
    :sunglasses: > 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 > :slight_smile:

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.

3

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 :slight_smile:

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 > :slight_smile: > 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
    :sunglasses: > 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 > :slight_smile:

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.