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



Reply via email to