RPC testing from Windows

David Fraser davidf at sjsoft.com
Wed Nov 13 03:42:49 CST 2002


Greg Turner wrote:

>>Doesn't work between Linux and a Windows machine 
>>(Linuz client sends
>>messages locally, client on Windows machine returns exception) 
>>    
>>
>
>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).

>
>  
>
>>but I guess that's because of the transport limitation?
>>    
>>
>
>The transport limitation, yes, but it's a far more profound problem than 
>just that.  Eliminate the transport limitation (which might be fairly 
>easy to do by fixing some bugs), and much deeper problems will rear 
>their ugly heads:
>
>o endpoint mapping isn't implemented correctly.  Thus, your windows
>  box will query your linux box (or the other way around), and find
>  itself unable to locate the right RPC service.  This problem won't go
>  away until the rpcss_kludge_{client,server}.c units go away and are
>  replaced by standards-compliant RPC-based services.
>
>o Even once that is done, we are left with the open issues regarding
>  listening on priveleged ports, running as root, and fighting with
>  SAMBA or DCERPC for control of the RPC name- and
>  endpoint-mapping-serviecs, as have been recently discussed on
>  wine-devel.  Fixing this may require some collaboration with the Samba
>  team, or some other creative solution.  It's a sufficiently distant,
>  and hairy, problem that I've been ignoring it, although I still mean
>  to make some attempt to communicate with the Samba folks to let them
>  know whats going on over here in wine country in the short term.
>
>  
>
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.
OK, maybe this is a really silly idea and we should wait until it works 
properly.
But if there is a quick way, then that would allow us to test the 
interoperability
between Windows and Wine RPC from the start...
Just a thought
David

 




More information about the wine-devel mailing list