[
https://issues.apache.org/jira/browse/QPID-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668458#comment-13668458
]
Gordon Sim commented on QPID-4854:
----------------------------------
Actually, the current heuristic *doesn't* really work - at least not as a DOS
prevention. It simply counts the number of reads, but with very little effort
at all you can create a client that write the protocol header, writes three
bytes each with a slight interval between them, and thus tricks the current
solution into cancelling the timeout while leaving a socket open without having
gone through any handshaking.
This makes the value of the current hack even more questionable in my opinion.
> max-negotiate-time feature breaks AMQP 1.0
> ------------------------------------------
>
> Key: QPID-4854
> URL: https://issues.apache.org/jira/browse/QPID-4854
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.20, 0.22
> Reporter: Gordon Sim
> Assignee: Andrew Stitcher
> Fix For: Future
>
>
> It has assumptions based on 0-10 (and a particular pattern for 0-10 at that)
> built into the underlying transport code (which should be protocol agnostic).
> As AMQP 1.0 makes it much simpler and more likely for less synchronous
> handshaking, the '3 reads' magic doesn't work and causes 1.0 connections to
> be terminated incorrectly. Either the original solution needs to be
> reimplemented or it needs to be possible to disable it for use with 1.0.
> See QPID-4021 and QPID-2518.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
