Hi Chris,

Please keep in mind how this came to life.
We always discussed a sensible and driver specific ping method, like in the S7 
case do a query against the slz or so.

This is the best approach.

The current approach works very inoptinal as observed in many applications from 
us and also Gunter. Thus, I see this as a first step from not so good to a bit 
better.
But ideally we implement something really good for each protocol.
At least now we observe disconnects way faster as before which is important in 
many use cases.

Julian

Von meinem Mobiltelefon gesendet


-------- Ursprüngliche Nachricht --------
Betreff: Re: Some of the latest changes
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:

Another problem I am seeing is that there is a great difference between ping 
and isConnected.

Ping simply checks if there is someone answering at the other side. While 
isConnected also gives an answer to the current state of the protocol 
connection.

So it is for example possible to still have a valid TCP connection but the 
protocol has already said goodbye and therefore the connection is disconnected. 
Or which is much more likely, the TCP connection has just been established, 
however the handshake has not yet been successful. Especially with protocols 
like S7 and EthernetIp where the connection requires multiple interactions with 
the remote and there is a goodbye in the protocol,
This is important.

Chris

Am 01.04.19, 10:48 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

    Hi Matthias and all others,

    Well actually, prior to these changes, the AbstractPlcConnection didn't 
have any code that was somehow related to the way communication is done. It 
sort of just provides the default implementations for all of our APIs functions:
    - readRequestBuilder
    - writeRequestBuilder
    - subscribeRequestBuilder
    - unsubscribeRequestBuilder
    ...
    So implementations only need to implement the methods it actually supports 
and for all others the default PlcUnsupportedOperationException throwing 
versions are used.

    Currently the part where the underlying connection-media comes in is in 
NettyPlcConection but here it's still agnostic to the type of connection ... So 
both serial and ip based connections use the same base-class.
    The type of connection is here passed in via the ChannelFactory where 
currently the following flavors are available:
    - TcpSocketChannelFactory
    - SerialChannelFactory
    - RawSocketChannelFactory
    - UdpSocketChannelFactory (Doesn't exist but would need to implement this 
for KNX protocol)

    So instead I would suggest to move the ping method into the ChannelFactory 
instead and to implement the isConnected method in the NettyPlcConnection 
class, which then uses the ChannelFactory's implementation to actually do the 
check.

    Chris



    Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan" 
<matthias.strl...@isw.uni-stuttgart.de>:

        Hi Chris,

        There I would throw in a counter-question, namely whether it would be 
important at this level to distinguish between automation protocols and 
fieldbus systems as AbstracConnectors? Because Profinet and EtherCat are 
protocols that differ a bit from the data handling of an OPC UA, ADS or S7 and 
are also quite sensitive regarding the deterministic real-time (EtherCat is a 
bit looser). Those types need a bit more configuration information like message 
structure, pull rate and master node.

        Then, of course, it would have to be evaluated whether these two 
communication systems should be separated and whether automation protocols 
exist on a basis other than TCP/UDP?
        Just take it as creative discussion point.

        Greetings
        Matthias Strljic, M.Sc.

        Universität Stuttgart
        Institut für Steuerungstechnik der Werkzeugmaschinen und 
Fertigungseinrichtungen (ISW)

        Seidenstraße 36
        70174 Stuttgart
        GERMANY

        Tel: +49 711 685-84530
        Fax: +49 711 685-74530

        E-Mail: matthias.strl...@isw.uni-stuttgart.de
        Web: http://www.isw.uni-stuttgart.de

        -----Original Message-----
        From: Christofer Dutz <christofer.d...@c-ware.de>
        Sent: Monday, April 1, 2019 10:06 AM
        To: dev@plc4x.apache.org
        Subject: Some of the latest changes

        Hi all,

        today I simply have a little time to inspect the latest changes as I 
was travelling for 5 days ... I do have a few questions:

        Why is AbstractPlcConnection been extended by a getInetSocketAddress 
method?

        PlcConnections are not bound exclusively to TCP/UDP ... we currently 
already have Serial port based connections and when going into protocols like 
Profinet and EtherCat in the future we'll be going down to IP or even Ethernet 
level.
        I don't like TCP/UDP details in the base abstract class for all drivers.

        ... continuing to evaluate ...

        Chris




Reply via email to