Greg Turner wrote:
This patch doesn't implement the resolve_rpc_endpoint server message yet, although my "final" (ya right) submission will include an untested implementation (I don't think the interop sample uses this API (or does it?) and that's the only known working test case right now). Either way, my test-case somehow manages to work without it ATM.
Just to verify, I tried running the interop sample and it works fine locally. Doesn't work between Linux and a Windows machine (Linuz client sends messages locally, client on Windows machine returns exception) but I guess that's because of the transport limitation?
David
On Monday 11 November 2002 02:29 am, David Fraser wrote:
Just to verify, I tried running the interop sample and it works fine locally.
Great! glad to hear this works for more than just me :)
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.
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.
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
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.
-
David Fraser -
Greg Turner