Re: comm_failure for large sequences using giop betweentwo machines



Hi Bowie,

On Thu, 2003-06-19 at 02:33, Bowie Owens wrote:
> !is_auth && buf->msg.header.message_size > giop_initial_msg_size_limit

	Gack.

> My large messages exceed the giop_initial_msg_size_limit (256K) 
> substatially. So giop_recv_msg_reading_body fails and this eventually 
> causes the client to disconnect and generate the COMM_ERROR exception. 
> Removing the condition allows the test I sent yesterday to run to 
> completion.

	Oh dear; ok - so, I think the 'is_auth' flag needs to be set on the
connection the first time we receive a valid object key from it [ this
is how we do security ]. Better still, we could do this by grokking the
first fragment / few tens of bytes of the message - and then allow the
buffers to accumulate if it is for a valid object key.

> What is the purpose of the above condition? Is it to prevent a client 
> from performing an attack by sending very large messages?

	Yes.

>  Can it be removed? is_auth is determined by the protocol and therefore
> never set for IPv4, is that correct?

	It should be set after we've got a valid object key [ which contains a
large, strong random cookie - used for security ].

> These artificial limits pose a bit of a problem for the project I am 
> working on. Since the client and server may need to send and receive 
> very large sequences. Unfortunately, there is no way to predict 
> beforehand an upper limit on the size of the sequences.

	Right; so - this is in some ways a shortish term solution - although I
think we should have a configurable limit for messages [ I believe we do
in HEAD - via. some ORB parameter - I think you can also make it
ulimited somehow via that parameter too.

	Ultimately we need to re-hash the code slightly so we know when we can
detect whether the invocation is valid, and thus authenticated as early
as possible; rather than when we've read the whole message.

	Are you interested in looking into that ?

	Thanks,

		Michael.

-- 
 michael@ximian.com  <><, Pseudo Engineer, itinerant idiot




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]