search

dansimpson / amqp-js

A push enabled AMQP Client for Javascript
120 stars 10 forks source link

content body not fragmented based on frame_max #11

Open rade opened 12 years ago

rade commented 12 years ago

Message content bodies should be split across multiple frames when exceeding the negotiated maximum frame size (actually frame_max-8 since the size includes the header and frame end marker). Doesn't look like that is happening.

Currently the RabbitMQ server doesn't complain when clients send frames larger than the negotiated frame size. But that is a DoS vector and therefore we are planning to change the broker to reject such frames.

So amqp-js really needs to start performing the required fragmentation or things will break against future version of RabbitMQ.

dansimpson commented 12 years ago

It's been awhile since I have looked at the spec. Is there any standard mechanism for fragmenting a message into multiple frames? Which frame type do I specify in fragment frames? With that information, I should have no problems implementing it in a single place.

rade commented 12 years ago

Dan, apologies for the late reply...

The frame type to use for each fragment is 'body' (type 3), just as you are using now to transmit the entire body.

dansimpson commented 12 years ago

Thanks for the info. I will work on this in the next week.

alexfernandez commented 11 years ago

I think I got bit by this issue -- apparently RabbitMQ 3.0.2 actively rejects frames larger than frame_max, saying:

Unhandled connection error: FRAME_ERROR - type 3, all octets = <<>>: {frame_too_large,258117,131064}

The log in /var/log/rabbitmq/rabbit@server.log says:

AMQP connection <0.16900.0> (running), channel 2 - error:
{amqp_error,frame_error,
            "type 3, all octets = <<>>: {frame_too_large,863735,131064}",none}

and then:

fatal_frame_error

Using amqp@0.1.4 with rabbit.js@0.2.0. Please let me know if I can help in any way to pinpoint this issue.