Well I think there ist sort of protocol level logic and transport level logic. Both usually don't really have much in common. For example for every serial packet the serial transport logic waits for an ack message and if this doesn't come in a given time Re sends the packet.
I wouldn't want to mix that with the normal protocol logic. Chris ________________________________ Von: Łukasz Dywicki <l...@code-house.org> Gesendet: Donnerstag, 3. September 2020 00:42 An: dev@plc4x.apache.org <dev@plc4x.apache.org> Betreff: Re: Supporting different layers of protocols depending on the used transport Maybe a bit of idea.. I think we have abstract fields (not sure if types). Can we align both AmsData kinds somehow? After all the role of transport is to ship payload and all we want do do is unification of these at certain level in order to implement logic just once. From high level point of view it can be seen as: transport -> payload [-> mapping] -> protocol logic. Obviously we miss currently mapping part, which might be relevant for future cases also in CAN. Cheers, Łukasz Dywicki -- Code-House http://code-house.org > On 2 Sep 2020, at 17:20, Christofer Dutz <christofer.d...@c-ware.de> wrote: > > 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 > > > >
