Separate the TncSourceBase into the Command Part and the ProcessingThread Part
SeanSolberg opened this issue · comments
The TncSourceBase class provides a TCP server that uses the TncTCPBase as the underlying socket. Then, when data is received, it processes the received stream into "commands" that are then executed by a processing Thread by pulling one from the TncThreadPool. The problem with this is that it would be nice to use the TncThreadPool to handle server processing of a message without relying on this network protocol that defines the command mechanism. We would like to use this library and the TncTheadPool, but we have our own protocol. Because these two concerns are both implemented in the TncSourceBase, we would have to re-write our own replacement to this class to make it work with our message framing mechanism. If this class could be split into two concerns, one for processing received data within one of the threads in the threadpool, and the other for parsing the received data into messages, then we could more easily make our own protocol message handler and still benefit from the processing threadpool.
Thanks so much for such a nice comment.
This concerns the architecting of the library. There is much to be desired, which I am planning for version 8. It is going to be a complete new package, albeit having preserved most "user" level stuff, it will be totally different under the hood. NetCom7 will be preserved as-is, for those who have used it, so nothing breaks.
In Ver 8, I am planning first of all to support the standard rolling encryption most clients use now-a-days, while also having the option to use any other ciphers.
Currently, what you are trying to achieve can be done via the TncTCPServer, but you are right, you would have to put on the thread pool yourself, and this should be done on the object itself. This will actually ease on development for the TncSource. So, yes, much appreciated and noted, Ver 8.0 will be in the architecting you are proposing:
The TncServer and TncClient, will also have the thread pool, and the good thing is that this does not break at all their simplicity. They are supposed to be "raw" sockets, but at extreme speeds and being able to pick up every disconnect.
The complete suite will be again for the eighth time be redesigned from scratch, with optimum code performance and robustness at mind. This time I need to put encryption in the streaming socket, before all this is closed in a version that I am satisfied with.
Sorry for the late reply, I am currently on a physics project and it involves a very close schedule as I am noting down some semiconductor behaviours for a machine I am finishing. Please fell free to post any continued comments until we shape up version 8 for the community. You rarely see engineers capable of shaping stuff in their minds these days, and am very glad this community is still TOP NOTCH.
Best regards.