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 _______________________________________________ orbit-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/orbit-list
