RPC_S_INVALID_BINDING in client
Shawn Fessenden
RPC_S_INVALID_BINDING. Both RpcStringBindingCompose and
RpcBindingFromStringBinding succeed. The protocol is tcp (ncacn_ip_tcp) on
port 1054. I've tried several different protocol sequences with the same
result.
I found a reference on a DEC site that gives a little more info than just
"The binding handle is invalid": RPC Protocol ID in binding handle was
invalid. Well, it looks ok to me in it's string form:
569f2117-297a-4c65-afaf-352ecc0f3b75@ncacn_ip_tcp:\\\\PIII733[1054]
The server shown is the localhost. So can anybody shed some light on just
where I should start looking for problems?
Additional info: environment is Windows 2000 Pro, MSVC++ 6 SP3 using SDK
MIDL & RPC includes. Server must eventually run on everything from Windows
95 to Server 2003. Should I switch to pure VC? Is rpcrt4.lib hassling me
because of differences between MSVC & SDK? SDK libraries are included &
linked first anyway. Server and client are both standard MFC dialog apps.
Server uses:
status = RpcServerRegisterIfEx(ISnapRemote_v1_0_s_ifspec,
NULL, NULL, RPC_IF_AUTOLISTEN, cMaxCalls, NULL);
status = RpcServerListen(cMinCalls, cMaxCalls, TRUE);
(both succeed)
--
-SHAWN-
Gianluca Braccini
RpcServerUseProtseqEp() ?
Gianluca
"Shawn Fessenden" <shawn#no#@testech-ldt.#spam#com> ha scritto nel messaggio
news:qmWTd.8955$HN5...@newssvr31.news.prodigy.com...
Shawn Fessenden
> RpcServerUseProtseqEp() ?
Hi Granular. Yes, I'm using Protested:
// Start the remoting interface.
RPC_STATUS;
unsigned char pProtseq[] = "ncacn_ip_tcp";
unsigned char pEndpoint[] = "1054";
unsigned int cMinCalls = 1;
unsigned int cMaxCalls = 4;
status = RpcServerUseProtseqEp(pProtseq, cMaxCalls, pEndpoint, NULL);
if(status) AfxMessageBox("RpcServerUseProtseqEp failed");
status = RpcServerRegisterIfEx(ISnapRemote_v1_0_s_ifspec,
NULL, NULL, RPC_IF_AUTOLISTEN, cMaxCalls, NULL);
if(status) AfxMessageBox("RpcServerRegisterIfEx failed");
status = RpcServerListen(cMinCalls, cMaxCalls, TRUE);
if(status) AfxMessageBox("RpcServerListen failed");
In the mean time I've switched back to using all VC++, recompiling the .idl
with MIDL 5 & eliminating all SDK references & linkage. I thought that would
help, but I still get the same thing. No matter what transport I try to use.
At least the problem hasn't changed.
I dealt with this once a few years ago and didn't have this problem but
unfortunately I don't have the code any more. It was basically the same
thing. An MFC dialog on both ends.
--
-SHAWN-
Shawn Fessenden
The latest documentation states that RpcServerRegisterIfEx (on the server
side) *REQUIRES* a server version of Windows, yet the call succeeds! What's
this all about? Does that mean I can't use an auto-listen interface? That
kinda blows. That means I'll have to put the call to RpcServerListen in a
separate thread - so's my dialog can draw & function.
And speaking of RpcServerListen, the dox also say that if I'm using an
auto-listen interface then I don't have to call listen! Jebus. Is there just
a simple tutorial somewhere on using MS RPC? So far the one I'm using (the
SDK RPC tutorial) has been wrong on all points - and *it* doesn't work
either.
And there's all this stuff about registering endpoint vectors & crap. All I
want to do is remote a few simple functions. I don't really care what RPC
does, as long as it does it right. Could somebody just give me a basic
overview for the following requirements:
The server will run on any version of Windows (using Win32). The server is a
dialog that displays status information - remote function name, last hit
time and number of hits. I could care less what transport is used. TCP/IP is
common to all servers. If I have to specify a port, ok but I would rather
let it float.
The client initially is a simple dialog that allows calling all functions on
any server for testing purposes. The client's final form is a php extension.
It will run on Windows 2000 Pro but should be compatible with XP / Server
2003 and whatever future versions of NT that MS cooks up, with the exception
that I don't plan on doing that Longhorn stuff.
-SHAWN-
Shawn Fessenden
I have since blown off the auto-listen interface and created a server
application that is bare bones. It's a console app that simply registers a
protocol sequence, registers the interface and calls listen. The client has
the same problem. Here is the server (minus method implementation):
void main(void) {
// Start the remoting interface.
RPC_STATUS status;
unsigned char pProtSeq[] = "ncacn_ip_tcp";
unsigned char pEndpoint[] = "1054";
status = RpcServerUseProtseqEp(pProtSeq, RPC_C_LISTEN_MAX_CALLS_DEFAULT,
pEndpoint, NULL);
if(status) {
printf("RpcServerUseProtseqEp failed");
return;
}
status = RpcServerRegisterIf(ISnapRemote_v1_0_s_ifspec, NULL, NULL);
if(status) {
printf("RpcServerRegisterIf failed");
return;
}
status = RpcServerListen(1, RPC_C_LISTEN_MAX_CALLS_DEFAULT, FALSE);
if(status) {
printf("RpcServerListen failed");
return;
}
}
You can't get much barer than that. All calls succeed. The server *is*
listening. The problem has to be the client. It calls
RpcStringBindingCompose with the UUID of the interface, transport and port,
then RpcBindingFromStringBinding. The binding returned is apparently bogus.
Why? It's as simple as all get-out.
-SHAWN-
Gianluca Braccini
RpcEpResolveBinding() on the client side ?
Gianluca
"Shawn Fessenden" <shawn#no#@testech-ldt.#spam#com> ha scritto nel messaggio
news:qmWTd.8955$HN5...@newssvr31.news.prodigy.com...
Shawn Fessenden
> RpcEpResolveBinding() on the client side ?
No. So I added it. And it returns RPC_S_INVALID_BINDING.
--
-SHAWN-
Shawn Fessenden
Correction - that call succeeds. But the client still throws an invalid
binding exception.
--
-SHAWN-
Shawn Fessenden
Ok, so I went back through the tutorial code very carefully, and I found
that it was using hello_IfHandle. I didn't see this in the tut code
anywhere, so I declared RPC_IF_HANDLE ifHandle and used that.
This was wrong. Massively wrong. It's declared in the MIDL generated code.
When I used that handle, everything worked out ok.
I still have problems, but I think I can take it from here. The interface is
now making remote calls just fine. I have to specify servers by their IP and
I have some memory issues, but I can handle that.
Thank you Gianluca Braccini for your help. Viva Italia!
-SHAWN-
duncan
> I've got a problem in an RPC client. Any server method invocation fails with
> RPC_S_INVALID_BINDING. Both RpcStringBindingCompose and
> RpcBindingFromStringBinding succeed. The protocol is tcp (ncacn_ip_tcp) on
> port 1054. I've tried several different protocol sequences with the same
> result.
>
> I found a reference on a DEC site that gives a little more info than just
> "The binding handle is invalid": RPC Protocol ID in binding handle
> was
> invalid. Well, it looks ok to me in it's string form:
>
>
> The server shown is the localhost. So can anybody shed some light on just
> where I should start looking for problems?
>
> Additional info: environment is Windows 2000 Pro, MSVC++ 6 SP3 using SDK
> MIDL & RPC includes. Server must eventually run on everything from Windows
> 95 to Server 2003. Should I switch to pure VC? Is rpcrt4.lib hassling me
> because of differences between MSVC & SDK? SDK libraries are included &
> linked first anyway. Server and client are both standard MFC dialog apps.
> Server uses:
>
> status = RpcServerRegisterIfEx(ISnapRemote_v1_0_s_ifspec,
> NULL, NULL, RPC_IF_AUTOLISTEN, cMaxCalls, NULL);
> status = RpcServerListen(cMinCalls, cMaxCalls, TRUE);
>
> (both succeed)
>
In case any other poor fool experiences this issue and manages to stumble
across
this thread. The problem is likely you are including both of the midl
generated
stub files (xxxx_s.c, xxxx_c.c) in your server code. It confuses it as to
what
implementation it should be using for your remote call... and for whatever
reason inexplicable chooses to toss out the invalid handle nonsense.
Good luck!