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