Implementing IOCP as a transport mechanism?

Hi EvgenyK

ah ok!

But in this case the product can never evolve (see for example integrate the Grijjy channels).
ROServiceTester is a very useful accessory product. More than once I thought of writing one myself to be able to customize it but I never have the time to do it. So having the possibility of the source to make the community evolve it would be a very nice thing. But I also understand the “problem” of third-party components if they are no longer on the market.

If you have any ideas about improvement of Service Tester - you are welcome.

1 Like

CDK was indeed quite historic, and only old Delphi-ers knew about it

I thought it was acquired by DevExpress and they suspend its support after Delphi 7. But if you have DevExpress VCL subscription, you might still get its source code by contacting DevExpress or Julian their CTO directly.

This was one from 3rd party libraries. so it can be problematic to get them all updated for the latest version of Delphi.

@EvgenyK out of curiosity and because you have the experience, how problematic and most certainly hard is to align IOCP (like the one grijjy implemented) to RO SDK. The benefits are obvious but I’m sure that it was skipped due to its complexities, care to give details on the consideration?

Thank you.

Hi,

IOCP works in asynchronous mode only so it can’t be suitable for usual (non-async) methods where client waits result of execution.
Client-side won’t be much (if any) benefit from IOCP unless you are doing hundreds req/s from the same client (an in this case it means that you are doing something terribly wrong).
Currently RO SDK for Delphi emulates asynchronous requests via sending them via usual (non-async) requests.
Implementation of IOCP will require rewriting significant portions of RO SDK code so it can be a bit compilcatied and non-reasonable at this moment because only Grijjy library (XE8+, Windows&Linux only) supports it

2 Likes