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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 30 Jun 2022 19:28:30 +0200, R.Wieser wrote:

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)