Expose direct buffer send/receive about indy HOT 1 OPEN

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.

from indy.