Roadmap to 1.0
See original GitHub issueHi @plcpeople and all users of nodeS7,
We all love nodeS7 the project and all the possibilities it opens. The code has been maturing along the last weeks and months, but I see some improvement room to codebase, and therefore I’d like to propose and discuss a roadmap to the version 1.0.0
of this awesome project.
In my personal opinion, in this first milestone I’d like to see (and of course contribute to) a major refactor of the code, separating the logic, creating classes, and organizing the code, without introducing any new feature. This would make it much easier to understand and to maintain, also making it easier to introduce many new features. We could then have more guarantees for the future of the project.
I think we could create a Wiki page or a Project to summarize all the ideas and discuss them, what do you think?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:4
- Comments:20 (2 by maintainers)
Hi guys,
I’ve been slowly writing some code related to our roadmap to 1.0, as much as my free time allows. In the last days I’ve published here on GitHub a sketch of an ISO-on-TCP implementation, as part of the stack needed to establish communication to a S7 PLC. I think this implementation could live as a separate packet/project, as there are other protocols on the wild that also use ISO-on-TCP as the transport stream and could benefit from it, such as RDP.
There’s actually not much there yet, just a parser and a serializer implemented as transform streams. I’ve also written some tests to both based on captured packets of communications to S7 PLCs The idea would be to implement an ISO-on-TCP Socket class, extending the
net.Socket
class. The s7 connection could be built on top the this socket class, or it could only use the parser and serializer subclasses.What do you guys think?
Thanks for the invite! I’m glad to contribute 😃
Regarding Fast acknowledge, I don’t have any device here nor any dump to simulate but, from what I understand, the “fast ack” (at least as it’s currently implemented) is just a normal ISO-on-TCP
DT
telegram, but without data, and with theEOT
bit unset, signalizing that that there’s still more data to come. So this shouldn’t be a problem for the class, just the implementation of nodes7 would have to handle these emptyDT
s accordingly (by discarding them, probably)