Re: Supporting different layers of protocols depending on the used transport

[Christofer Dutz]

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.d...@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.d...@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