RPC testing from Windows

[Greg Turner]

On Wednesday 13 November 2002 03:42 am, David Fraser wrote:
> Greg Turner wrote:
> >Not sure if this is what you've encountered, but there is a
> > shortcoming of the current implementation: the client-side API's
> > report success even when they fail.
>
> Not just that; they currently send the message locally even if it was
> specified
> to send it somewhere else (which of course they can't do).

yup.  I think there may be some code in there to hash out the machine 
names for the tcp/ip transport, but, in addition to the endpoint 
mapping problem, I think there's some bugs...  Once RPCSS is submitted, 
I plan to spend some time dividing up the support for each transport 
into separate functions; we should probably treat the transports in an 
object-oriented manner, like DCERPC does.

> What would be the quickest way (even if it's a dirty hack) to allow
> another machine
> to connect to your RPC system? I was wondering if we could implement
> some system like the following:
>  A) is a machine running Linux, with your initial implementation of
> RPCSS B) is a machine running Windows.
> On B), we run a RPC server that takes all the messages it receives
> and sends it to
> A), kind of like a proxy.
> Then we could test out the client.exe, say on B), tell it to connect
> locally, but the
> message will then get rerouted by the proxy to another client on A)
> that sends it
> to the actual server.

something like this has occured to me too.  Certainly, at the very 
least, if SAMBA and RPCSS are going to coexist, there needs to be some 
entity, perhaps SAMBA itself, which coordinates between the two.  Throw 
DCERPC and freedce into the picture, as well, and we have a nice big 
mess brewing.

> OK, maybe this is a really silly idea and we should wait until it
> works properly.

It's not too silly for serious consideration IMO.  Although it may be 
premature to pursue an implementation just yet.

> But if there is a quick way, then that would allow us to test the
> interoperability
> between Windows and Wine RPC from the start...

The sooner the better; we can't really rest assured that we are doing it 
"right" (even if we conform to the real RPC standards) until we know 
that we interoperate with windows.  Since SAMBA works with windows, 
they obviously /do/ have it right, which is food for thought.

My thinking on the matter is that we should proceed as follows:

1) Ignore these issues for the moment, and work on marshalling for all 
the datatypes needed for the real endpoint mapping daemon, and 
strengthing the overall RPC architecture.

2) Get rid of the named-pipes hack (or perhaps we keep it around for 
local RPC's?), and implement the real endpoint mapping capaiblities 
using the new marshalling capabilities.

3) Now we're in a position to make sure we interoperate with Windows, 
and we're building on kludge-free foundation.

Somewhere between (1) and the completion of (2), we have to figure out 
this inter-deamon coordination issue (otherwise it's still not going to 
work).  It's also worth noting that we can try to make sure that wine 
interoperates with itself across hosts sooner than this, if we want.

-- 
gmt

"War is an ugly thing, but not the ugliest of things;
the decayed and degraded state of moral and patriotic
feeling which thinks that nothing is worth war is much
worse. A man who has nothing for which he is willing
to fight; nothing he cares about more than his own
personal safety; is a miserable creature who has no
chance of being free, unless made and kept so by the
exertions of better persons than himself."

-- John Stuart Mill