XPsp3 - How does NtAcceptConnectPort work ?

[R.Wieser]

Hello all,

I'm trying to create some basic LPC code, but am running in a bit of a
problem in regard to how NtAcceptConnectPort works. :-(

I've got some server-side code which uses the following functions in the
below order :

NtCreatePort
NtListenPort
NtAcceptConnectPort
NtCompleteConnectPort
NtReplyWaitReceivePort
...

On the client side I'm calling NtConnectPort twice (with some data
identifying each connection), to test opening two connections to the server.

The problem is that although I'm calling NtReplyWaitReceivePort with the
data-port handle returned from NtAcceptConnectPort the second connect
requests data is received by NtReplyWaitReceivePort.

Which, to me, is quite unexpected. It is as if the data-port handle is
absolutily ignored ...


Could someone explain to me how the above works / how I can make multiple
connections to the server-side program ?

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
Hello all,
I'm trying to create some basic LPC code, but am running in a bit of a
problem in regard to how NtAcceptConnectPort works. :-(
I've got some server-side code which uses the following functions in the
NtCreatePort
NtListenPort
NtAcceptConnectPort
NtCompleteConnectPort
NtReplyWaitReceivePort
....
On the client side I'm calling NtConnectPort twice (with some data
identifying each connection), to test opening two connections to the server.
The problem is that although I'm calling NtReplyWaitReceivePort with the
data-port handle returned from NtAcceptConnectPort the second connect
requests data is received by NtReplyWaitReceivePort.
Which, to me, is quite unexpected. It is as if the data-port handle is
absolutily ignored ...
Could someone explain to me how the above works / how I can make multiple
connections to the server-side program ?
Regards,
Rudy Wieser

Those functions are not meant for user applications. There're network level
functions used for RPC much like FTP or HTTP, which don't yet include
information regarding the source and destination applications.

While the client part of it can be used for user applications, the server
part while it's possible, it should not be used - as there can only be one
effective listener, since RPC data is not sent using network broadcast.
IOTW, only one listener will receive the data.

If the server part is used by user application, it may interfere with the
RPC server. Making some data not received by the RPC server.

[R.Wieser]

JJ,

the server part while it's possible, it should not be
used - as there can only be one effective listener

Which is exactly what I'm after. Multiple programs communicating over a
single RS232 connection - in a similar way TCP/IP works.

Making some data not received by the RPC server.

Its my preference (and the reason of using the posted functions) if *none*
of it is received by the *R*PC server. All of it is supposed to stay in the
local machine.



But, do you have any idea why the NtReplyWaitReceivePort, while being given
the handle returned by NtAcceptConnectPort, receives data that is send by
NtConnectPort (to create a new connection) ?

Although I've found some old MSDN information related to the arguments to
the NT port functions as well as a handfull of examples, I've not found
/any/ info about how those port functions interact (an their "gotyas").

Regards,
Rudy Wieser