File Server Client

[ad3154]

One major feature still missing (but started) is the ISOBUS file server client. So I am making this issue to track it, and so we can create a 1.0 milestone with it and other things that come up.

• Add file server client interface
• >=80% Unit test coverage

Side note, I know John Deere does File server (server side) in a way that I would call... bad. So if anyone has a John Deere terminal out there like a Greenstar 3 2630 or a 4th generation terminal of some kind, hit me up and we can test it!

[bjoernpoettker]

Hi,
I have two JD 4640 Terminals here, one on a Fendt tractor as taskcontroller for a manure spreader with a harvest lab and the second on a 9900i. Next to those I have got some CCI terminals (200, 800, 1200), an Amazone AmaTron 4 and Fendt terminals. If I can help you let me know!

[nullr0ute]

Someone has done an initial file server/client for the linux can-utils, not sure if that can be used/integrated for use here. Details: https://lore.kernel.org/lkml/[email protected]/T/#u

[ad3154]

Someone has done an initial file server/client for the linux can-utils, not sure if that can be used/integrated for use here. Details: https://lore.kernel.org/lkml/[email protected]/T/#u

Hello! I appreciate you pointing this out.

To be totally transparent here, I am not a fan of the kernel implementation of any of their J1939 or ISOBUS features. They are certainly "neat", and I appreciate the work of the devs expanding these features, but IMO those features are more or less useless for functional ISOBUS implement applications with more than trivial complexity. They obfuscate or at least deprioritize understanding of key concepts like control functions, they have an interface which I understand is blocking on transport sessions (like, the socket can't be used if it's sending a transport layer message) which makes it useless to me because multiple parallel protocols must be supported on an ISOBUS, and other reasons....

But my feelings aside, I don't think it is particularly useful for a number of technical reasons as well.

1. The license is more restrictive than ours (they are GPL 2.0), so we're already prevented from using it because of that
2. It's C, and we're targeting C++ for core functionality
3. It has socket CAN and other OS specific dependencies, whereas our implementation must be platform agnostic
4. My understanding is that the kernel J1939 interface (and this by proxy) obfuscates the network management layer of the bus too much for it to be useful to us, and generally is synchronous, which both don't play well with our project.

We could use it as reference material, to see how they solved certain problems, but in the end I think the way we get the best result in our library is by using the ISO11783-13 standard to drive the interface's structure.

Our implementation of the FS client has admittedly been slow for a few reasons, but we'll get it done! It is mostly functional already, but if I recall correctly it just needs better support for parallel operations and unit test improvements. That, and some refactoring of our network manager, are the last things standing between us and a 1.0.0 release of the library I think.