Implementing IOCP as a transport mechanism?

On a future version of RO, they will be implementing some of the protocols based on the Grijjy open source communication classes. Grijjy implemented IOCP on them, even if RO doesnt directly support them (hopefully they will) it could be possible to modify them so they can be used.

Here it is a link to their source regarding IOCP.

Is IOCP included already with RoSDK latest release?


We have implemented a few Grijjy-based channels in ROD v10:

  • TROGrijjyHttpChannel
  • TROGrijjySuperHttpChannel
  • TROGrijjySuperTCPChannel
1 Like

I have 2 questions:

  1. Are all of these three channels using IOCP, or just the HTTP channel?
  2. They are not included in the Service Tester? Can we have them in the Service Tester?


Though TgoHttpClient supports blocking and non-blocking modes, we use it only in blocking mode so
IOCP won’t work for this component.

will add Grijjy channels to Service Tester

I see.

So the value of these Grijjy based new components, is not about IOCP, but about the capability of being cross-platform. Is that correct?

Yes, they work for Windows and Linux platform and can be replacement for users who dislikes using Indy components.

bugs://83479 got closed with status wontfix.

Grijjy channels aren’t compatible with Delphi7 that is used for compiling Service Tester …

Understand. Not a problem.

Hi EvgenyK

it would be great if you will can release the source code of the ROServiceTester on github (only users with a license) so we can add the missing features, port the product to new versions of Delphi, etc. etc…

Best regards


see mh’s answer at RO SDK Service Tester is buggy, why not "open-source" it for licensed users?

1 Like

Thank EvgenyK

I had missed the answer! For the third-party components most of us probably already have them :wink:

Service Tester uses a lot of 3rd party components are released in 2006.
Some of them don’t exist anymore, like Eagle Software CDK, etc
I don’t think, that anybody except us continue to use them

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.


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