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" <[email protected]>:
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