"Huang Xiaobin" <hxbtougao@yahoo.com.cn> wrote in message
news:44376128@newsgroups.borland.com...
> RFC2229 said that the implementation for the Dictionary Server Protocol
> MUST accept multiple commands in a single TCP send operation(ie,
> should give PipeLine property like TIdSMTP does), but i found
> IdDICTServer didn't support it.
Yes, it does. Indy already implicitally supports pipelining on all of its
sockets, so there is no need for extra support in TIdDICTServer
specifically. All pipelining does is allows the client to combine multiple
commands into a larger TCP packet, and to allow the server to combine
multiple responses into a larger TCP packet, so that fewer calls to the
lower-level socket API send() and recv() functions are being made. That
does NOT mean that individual lines contain multiple commands. Individual
commands and responses are still required to be separated on their own
lines, separated by CRLF characters. The pipelining merely allows the
lower-level network transmissions to operate more efficiently, nothing else.
Since Indy already receives all inbound data in bulk packets automatically,
pipelining for inbound data is already implictally implemented on all Indy
connections. As for piplining outbound data, that is simply a matter of
calling the TIdTCPConnection.OpenWriteBuffer() (Indy 9) or
TIdIOHandler.WriteBufferOpen() (Indy 10) method prior to writing data to the
connection.
> Actually, i found TIdCommandHandler.Check didn't accept multiple
> commands in single line
The DICT protocol does not allow multiple commands per line to begin with,
as is clearly defined in Section 2.3. That is not what pipelining is about.
Gambit
