plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: Supporting different layers of protocols depending on the used transport
Date Wed, 02 Sep 2020 15:20:01 GMT
Hi ... bumping this thread back to life due to recent user-requests.

__ 

@Julian ... would you be able to provide me with some empty extension stub to implement something
like in below email?

Perhaps we should have a "withDefaultTransportProtocol" too ... as we do have a lot of transports
(tcp, udp, serial, pcap, passive, can?, ...) 
I think usually we'll have one default transport and we wouldn't have to register handlers
for every transport.
So in the example below I would propose:

    @Override
    protected ProtocolStackConfigurer<AmsPacket> getStackConfigurer() {
        return SingleProtocolStackConfigurer.builder(AmsPacket.class, AmsPacketIO.class)
            .withProtocol(AdsProtocolLogic.class)
            .withDefaultTransportProtocol(AmsTCPPacket.class, AmsTCPPacketIO.class, AmsTcpTransportProtocol.class)
            .withTransportProtocol("serial", AmsSerialFrame.class, AmsSerialFrameIO.class,
AmsSerialTransportProtocol.class)
            .littleEndian()
            .build();
    }

This would only use the special AmsSerialTransportProtocol if the transport is "serial".


Chris



Am 12.08.20, 09:59 schrieb "Christofer Dutz" <christofer.dutz@c-ware.de>:

    After a little discussion with Julian we realized we need a little more:

    First of all using fixed classes to decide which branch to use makes it impossible to
test using the embedded channel. 
    Using a "transportFamily" property which each transport provides, makes this possible.

    Also do we have to use a different Encoder/Decoder for processing the packet depending
on the used transport.
    So the AmsTcpTransportProtocol would be expected to consume AmsTCPPacket objects and produce
AmsPacket objects.

    @Override
    protected ProtocolStackConfigurer<AmsPacket> getStackConfigurer() {
        return SingleProtocolStackConfigurer.builder(AmsPacket.class, AmsPacketIO.class)
            .withProtocol(AdsProtocolLogic.class)
            .withTransportProtocol("tcp", AmsTCPPacket.class, AmsTCPPacketIO.class, AmsTcpTransportProtocol.class)
            .withTransportProtocol("serial", AmsSerialFrame.class, AmsSerialFrameIO.class,
AmsSerialTransportProtocol.class)
            .littleEndian()
            .build();
    }

    I bet this is gonna be some crazy generic stuff ... 

    Chris

    Am 12.08.20, 09:04 schrieb "Christofer Dutz" <christofer.dutz@c-ware.de>:

        Hi all,

        taking this back to the list as I think it belongs here.

        While working on the ADS driver I noticed that we might have the need to pack a given
protocol in different transport protocols, depending on the used transport.

        For ADS it has to either wrap the AMSPacket in a AmsTCPPacket if using TCP or in a
AmsSerialFrame if it’s using serial. For serial also some ACK packets have to be created
or processed.

        I wouldn’t want to mix that in to the driver itself as this should only worry about
the AMSPacket logic itself.

        So I was thinking if it would be possible to do something like this:

        @Override
        protected ProtocolStackConfigurer<AmsPacket> getStackConfigurer() {
            return SingleProtocolStackConfigurer.builder(AmsPacket.class, AmsPacketIO.class)
                .withProtocol(AdsProtocolLogic.class)
                .withTransportProtocol(TcpTransport.class, AmsTcpTransportProtocol.class)
                .withTransportProtocol(SerialTransport.class, AmsSerialTransportProtocol.class)
                .littleEndian()
                .build();
        }

        Any thoughts?
        We probably have to extend the transports to return a “family” of transports so
we can for example say that Raw-Socket and PCAP-Replay are “TCP” or “UDP” and for
the EmbeddedTransport I would need to be able to configure what it should be.

        Chris




Mime
View raw message