MARS Server (Service) - Additional TCP connections to NON REST Clients

[marcovaldo 1]

Hi All,

I am working on a MARS Server (runnable as Application AND as Service).
MARS REST interface is used to communicate with Enterprise IoT Servers (eg. Upstream comms)
The same Server also shall communicate using various TCP protocols to IoT Sensors (eg Downstream comms)

? What TCP library would you recommend to use for this ?

- Indy is used by (the stand alone server of MARS).
  Its a blocking/synchronous library (the downcomms will have to be moved into threads)
  ? Might using this interfere with the MARS internals?

- ICS - I was very happy using this over the years in kind of Bread and butter VCL apps.
  But not sure if they depend much on Windows Message Loop / Events and
  might be difficult to handle in a Windows Service/ Multithreading enviroment
  (I will have to implement much to keep the engine under the hood running)
 (I think there is a Multiping Example by Angus Robertson at least, which might help me)
  ? Is it better to go for Indy or even for the Synapse lightweight library - because
   a linear comms task in a thread is simpler structure than all that message pump ens Event stuff ?


Many thanks in advance for any suggestion guiding my half-noob in a swampy area!

Seasonal Greetings & a good 2022!

marcovaldo

Edited December 19, 2021 by marcovaldo

[marcovaldo 1]

Always finding first answers _after_ posting something...
(I can confirm I have searched around before posting...)

On ICS in Service and Application Example (Thx François Piette!)

 

[Fr0sT.Brutal 900]

I doubt having 2 big network libs in a project is nice idea. Though, everything depends on how many connections you'll have. 1000s of threads won't be a good solution either.

[marcovaldo 1]

54 minutes ago, Fr0sT.Brutal said:

I doubt having 2 big network libs in a project is nice idea. Though, everything depends on how many connections you'll have. 1000s of threads won't be a good solution either.

Hi,

Thx for your suggestions!

In the meantime I am looking more into Using ICS for the downcomms. Something event driven might be easier for implementation with complex protocols handling many different
kinds of protocols (needing timeouts, single byte answers etc.)
Unfortunately there will be lost of (partially yet undefined) downstream protocols...

And if I use Indy for the MARS (Uplink side) only I can later on decide to convert to apache module (NO - i think this will not work; Apache Module will run in a Apache Request/Answer Thread and
will not have means to keep connections with the IoT sensor nodes continously )

Greetings,

    Marcovaldo

[Fr0sT.Brutal 900]

Just remember that async model is much more complex to implement correctly. You have to build state machine and consider all possible cases. In addition, unexpected things could happen when mixing async and sync methods (i.e., if in the handler of an async event you run some sync methods that lead to socket destruction - you likely will get AV).