Expose direct buffer send/receive

[gec75]

I have a special device which has a high data throughput... For this case, I want to bypass all internal buffering (I have my own simple line handling) and use low level socket select/send/receive. But currently Send/Receive only work via TBytes.
I can reach hundreds Mb/s... even though the PC can handle that, I want to avoid intermediate copies.

Currently I use TIdSocketHandle (after connect), but have to hack via TIdStackBSDBase.WSRecv...

Is there a reason NOT to allow direct buffer access?
It would be an easy interface addition with overloaded functions...

indy_ll_buffer.patch

[rlebeau]

The whole reason that TIdBytes was introduced in Indy 10 in the first place was to support .NET, where using raw pointers is not allowed (or at least not easy/feasible to use). Rather than IFDEF'ing the code all over the place, everything was consolidated on TIdBytes to keep the code clean. Yes, that can cause some performance degradation on non-DotNet platforms.

Fortunately, support for .NET is being dropped in Indy 11, so there will be opportunities for Indy to use/optimize raw buffers again, as it did in Indy 9 and earlier.

Otherwise, one way you can use your own buffers with Indy 10 is to use the TId(ReadOnly)MemoryBufferStream classes with the IOHandler.ReadStream() and IOHandler.Write(TStream) methods. That won't completely eliminate all TIdBytes use (ie, ReadStream() reads from the IOHandler.InputBuffer which uses TIdBytes, and Write() uses a local TIdBytes), but it will reduce the usage.

That being said, if you need high-performance low-latency I/O, and if you are using Windows, then consider using WinSock's Registered I/O extensions, which will allow you to use your own buffers even inside the socket itself. While Indy itself does not use RIO, its IdWinsock2 unit does expose access to the RIO API.