Re: [PATCH] New function to deduce ORB capability

[Jules Colding <colding omesc com>]

On Wed, 2006-04-05 at 15:58 +0800, KC wrote:
> Hi,
> 
> As DoS attack is concern, I totally agree with you.
> 
> But I still think, at least, we should allow system administrator
> to bypass this limitation.
> 
> For example, provide new API,
> ORBit_set_giop_recv_limit(0)
> to disable the limitation check.
> 
> Why ?  Because only system administrator know whether
> the network will under DoS attack or not.   Only system
> administrator know what is the best configuration for
> his environment.

It's a little more complicated... There is already an option to
explicitly set the recv limit. It the "ORBInitialMsgLimit" orb option.
You can set the limit to anything using that option but you can not
disable the limit check at all check. The lowest possible recv limit is
257 bytes. There is no maximum expect for the largest possible value of
the internal limit type which is "glong".

Everything would be much more simple if any client could use the
"ORBInitialMsgLimit" orb option to disable the limit check or set the
limit as high as possible but, due to an unfortunate design limitation
in ORBit2, that is not possible.

The, IMHO, design mistake is that all subsequent invocations of
ORB_init() will return a copy of the first ORB to be initialized. This
has the unfortunate effect that the first thread to invoke ORB_init()
will set the capabilities of all subsequent ORBs to be "created" by any
subsequent thread.

In other words: If the first thread to invoke ORB_init() decides upon a
particular set of orb options then all subsequent threads will just have
to live with that choice.

So we basically have two choices here:

1) A client thread that needs an ORB with a particular set of
capabilities will have to detect and work around the choices imposes by
the first thread to invoke ORB_init(). The stream data retrieval loop is
an example of that strategy.

2) A client thread could decide that it can not work around the limits
imposed upon it by the first thread that invoked ORB_init(). Its only
choice to continue operation is therefore to launch a proxy application
that will proxy ORB operations on its behalf. I am doing that right now
in my evolution-brutus plugin.

A method to disable the incoming data GIOP limit is only useful if the
client application has full control over ORB creation. Any other
application type will have to work around these rather artificial
limits.

It would be rather simple to export a function that disables the imposed
recv limit, but that function would then change the capabilities of the
ORB as set by the first thread. Any such change would be invisible to
the first thread. I really do not believe in doing that. Changing the
behavior of an ORB while another thread assumes certain
limits/properties of the ORB is not acceptable IMHO.


> In my application (local distributed DAQ system), the client/server
> sit in the same private network ...  because I'm working on
> DAQ system ... anything that will improve performance will
> be a good choose for me.

You can always build a locally hacked up version of ORBit2 that disables
the limit. See giop_recv_set_limit() line 929 in giop_recv_buffer.c and
anywhere giop_initial_msg_size_limit is referenced.


Best regards,
  jules