Could ONCRPC4J be embedded in an existing server?

[oscarlantz]

Hello. In my project (Electronic Access Control) we are looking to replace an old ONCRPC implementation in the server with something new. But we still need ONCRPC to be compatible with existing door controller hardware. Our old implementation has the feature to embed the ONCRPC server in an existing server by creating the ONCRPC server with an input- and an output stream. Our solution is built that way because we have several protocols talking on the same server port.

So my question is can ONCRPC4J be embedded some way? Prefferably using asynchronous channels.

Regards, Oscar Lantz

[kofemann]

Hi,

thanks for your interest in oncrps4j. I am not sure that I am understang you question correct. Could you share small example of how it's used currently and we will see hot this can be implemented with oncrps4j.

Tigran.

[oscarlantz]

Thanks for the quick reply. Here is our class that connects a channel in our MUX with the ONCRPC server using the MUX channel streams. The MUX can be descibed as wrapper around a socket that can talk different procols by opening different channels in the MUX and still talking through the same socket.

public class MuxRPCConnector implements MuxChannelConnector { private static final Log LOGGER = LogFactory.getLog(MuxRPCConnector.class.getName());

private OncRpcDispatchable dispatcher;
private OncRpcServerTransportRegistrationInfo[] info;

public MuxRPCConnector(OncRpcDispatchable dispatcher, int program, int version) {
    this(dispatcher, new OncRpcServerTransportRegistrationInfo[]{new OncRpcServerTransportRegistrationInfo(program, version)});
}

public MuxRPCConnector(OncRpcDispatchable dispatcher, OncRpcServerTransportRegistrationInfo[] info) {
    this.dispatcher = dispatcher;
    this.info = info.clone();
}

@Override
public void connectChannel(MuxChannel channel) {
    try {
        Object id = channel.getMux().getMuxId();

        OncRpcStreamConnectionServerTransport transport = new OncRpcStreamConnectionServerTransport(dispatcher, id, channel.getInputStream(), channel.getOutputStream(), info, 8192, null, 3000);
        //
        // Let the newly created transport object handle this
        // connection. Note that it will create its own
        // thread for handling.
        //
        transport.listen();
    } catch (IOException | OncRpcException e) {
        LOGGER.error("exception when creating server transport", e);
    }
}

}

The MUX is our own code so we could possibly change that to communicate in an asynchronous way.

We are using a really old version of Remote Tea (1.0.0), which is not in maven central. And when I asked the author he didn't have the source code any more.

org.acplt.oncrpc oncrpc 1.0.0

/Oscar

[kofemann]

Wow! This is very interesting code fragment. I don't think you can do this with RPC only. There should be a some kind of custom code to implement this.

Let look at it from a different point of view: If you need streaming, why use use RPC?

If you need the RPC, then what you application expects from the stream? Do you write RPC messages into it and read back replies?

Tigran.

[oscarlantz]

Yes, the MUX is a custom built binary protocol that enables tunneling of different protocols in the same socket. I've tried to explain it better in this picture:

http://webwhiteboard.com/export/ucd3bgwqqyzd.png

To not loose backward compatibility we need to stick to ONC RPC.

[kofemann]

It is still not clear to me. Is MUX a RPC based protocol or it uses some other mechanism from org.acplt.oncrpc to simulate stream?

[oscarlantz]

You can think of the MUX almost as a VPN tunnel (or an SSH tunnel). Just like you get streams from a network socket (the old I/O api in Java) we get streams from a MUX channel. The mux is our own binary protcol to achieve this tunneling. So yes it is another mechanism to simulate streams. And thus we are not using the network transport part of ONC RPC.

Our main purpose for looking at another ONC RPC implementation than the one we use today is to have a more scalable solution and to avoid one thread per connection to be created in the RPC server. We can also change the server (java) side of the MUX channels to use non blocking I/O instead of streams.

[kofemann]

Now I am completely confused. I got the point with the tunneling. MUX provides a virtual stream and you need a RPC calls to utilize it. In other words, you need RPC to use stream provided by MUX as a transport. Is it correct?

[oscarlantz]

Sorry to confuse you :-). Yes you are correct. The MUX is the transport. So what do you think, would it be possible to use ONCRPC4J with another transport than TCP or UDP either by regular java streams or some non blocking I/O mechanism?

[kofemann]

Ok. It should be not too difficult to add it. I will thick a bit about it and will let you know.

Thanks, Tigran.