plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: Supporting different layers of protocols depending on the used transport
Date Wed, 02 Sep 2020 22:42:13 GMT
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.dutz@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.dutz@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.dutz@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
> 
> 
> 
> 

Mime
View raw message