On 1/3/07, Damjan Jovanovic damjan.jov@gmail.com wrote:
On 1/4/07, Matthew Edlefsen matt.edlefsen@gmail.com wrote:
On 1/2/07, Damjan Jovanovic damjan.jov@gmail.com wrote:
On 1/1/07, Matthew Edlefsen matt.edlefsen@gmail.com wrote:
Hi, I've been trying to get a program that uses rpc to work on wine
and
I've
been having some problems (my understanding is that isn't
surprising).
The
goal is to be able to run a rpc server that sits and waits for
connections
over tcp/ip (It's for doing distributed computing). My first
problem
was
that I was using RpcServerUseProtseq which after looking at the code
noticed
will always fail with tcp/ip since it passes RpcServerUseProtseqEp
NULL
for
the endpoint which eventually causes rpcrt4_protseq_ncacn_ip_tcp_open_endpoint to call getaddrinfo with NULL for both the ip and port which I guess isn't
allowed.
Anyways I altered my code to use a given endpoint instead and now it
tells
me: fixme:rpc:RpcMgmtWaitServerListen not waiting for
server
calls to finish
Ah yes - that one!
Does this mean the function just doesn't work? Is there any way
around
it?
It does work. After calling RpcMgmtWaitServerListen, just sleep forever. The RPC function calls come in on a different thread anyway.
Ah great, thanks.
I assume if it was easy to implement it would have already but just
in
case
what exactly needs to be done to get it working?
I was wondering this too, Robert might know.
I was also confused by the differences between the online git tree and the LXR/what actually
gets
downloaded to my computer.
To be honest I'm pretty new to wine and linux in general but it
would be
absolutely wonderful to get this working.
Good luck.
Thanks in advance - Matt Edlefsen
Damjan
I set my server to sleep right after it starts listening but I still
can't
connect to it for some reason. You (or anyone else) don't happen to
have
any example code that you know works that I could start with? Anyways, thanks so much for the help - Matt Edlefsen
I'll try running my test code on the latest wine and send it if it works.
Is the port open?
Damjan
Pretty sure. The only reason I say that is that when I test it I have to change to the port every test because if I don't it says the port is in use (I guess the program isn't closing the port or something). Honestly I still don't fully understand how rpc finds the port number, which may be the problem. When using RpcServerUseProtseq on Windows, according to msdn, "the port number is dynamically determined by the RPC run time, depending on availability and registry settings." If that's the case how does the client know what port to connect to? Since I'm using RpcServerUseProtSeqEp instead on Linux would that change things? I'll try specifying the port in the client and seeing if that works.
Matt Edlefsen