Re: [PATCH] New function to deduce ORB capability

[KC <kcc1967 gmail com>]

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.

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.

FYI.

Regards
KC



On 4/5/06, Jules Colding <colding omesc com> wrote:
> Hi,
>
> On Wed, 2006-04-05 at 08:05 +0800, KC wrote:
> > Export API, ORBit_get_giop_recv_limit(), is GOOD and
> > necessary for large data stream transfer.
>
> Agreed.
>
> > However, why not simply hide this limit inside internal
> > implementation ?   And let both stub/skeleton code
> > handle the fragment automatically ?
> >
> > I don't know how difficult it will be, just think that should be
> > more reasonable from end user's point of view.
> >
> > IMHO, the size limit should only affect ORB's performance,
> > and should be invisible from client.   It is system
> > administrator's task to deices how big the size limit should be
> > instead of the client writer.
>
> The limit seems to be very intentionally introduced to prevent DOS type
> attacks. There is no such limit for outgoing data. The rationale seems
> to be that the client has full control over the amount of data that are
> outgoing but has no control over the amount of incoming data.
>
> I therefore think that it is better to make the client application
> intentionally accept large incoming data streams instead of hiding the,
> in many ways, artificial loop over the incoming data chunks inside the
> stub/skeleton code.
>
>
> Best regards,
>   jules
>
>
>
>