Perhaps, instead of even having InitializeMTUPropertyValue(), change SLPNetworkSetSendRecvBuf to getsockopt, see if it's greater than global.mtu, and if not setsockopt to global.mtu. That would provide the minimum change (and therefore minimum new side effects) to how the sockets work.
If we must keep InitializeMTUPropertyValue, it should do a getsockopt and compare before setting the MTU. If the socket option is larger than global.MTU, I would prefer that we don't actually change the socket options. The existing code doesn't touch the socket buffer sizes, and it is unknown what side effects will happen if we start limiting them. And the default receive buffer size is often larger than the default send buffer, so limiting them both to the same value could also have side effects. Thanks for looking at this! --Nick On Mon, Aug 23, 2010 at 6:36 AM, Venkateswara R Puvvada <vpuvv...@in.ibm.com > wrote: > > Hi Nick, > > I have incorporated your review comments and uploaded the patch to the > bugzilla. Please let me know if you have any further comments. > > Venkat > > > > *Nick Wagner <ne...@wingedbeast.org>* > Sent by: nwagner...@gmail.com > > 21/08/2010 02:47 > To > Varun Chandramohan <var...@linux.vnet.ibm.com> > cc > openslp-devel@lists.sourceforge.net, "Morrell Richard (external)" < > richard.morr...@uk.thalesgroup.com>, Venkateswara R > Puvvada/India/i...@ibmin, Madhuri D Madhavanpillai/India/i...@ibmin > Subject > Re: [Openslp-devel] Regd: Openslp MTU issue > > > > > I think a similar change could be made to the slpd_socket.c, and I would > check the other areas that call socket(). Instead of just setting the > options, I would also do a get and compare with mtu. Some OSs have quite > large values for those options already (sometimes greater than 65535), no > need to shrink them down. > > --Nick > > 2010/8/20 Varun Chandramohan > <*var...@linux.vnet.ibm.com*<var...@linux.vnet.ibm.com> > > > Hi Nick, > > The patch is updated in the tracker, can you have a look at > this? Let us know if its ok? > > Regards, > Varun > > On Friday, August 13, 2010 09:54:48 am Varun Chandramohan wrote: > > Hi Nick, > > > > I think you are right. May be we should have a check for > that. Iam adding the author of the patch to this mail. He is not subscribed > to this ML, so please do reply all > > so that he is kept in loop. In our labs we have had major issues to get > this working. If you have suggestion do let us know so that we can address > this at the earliest. > > > > Venkat, > > Can you look into this issue? > > > > Regards, > > Varun > > On Friday, August 13, 2010 12:32:46 am Nick Wagner wrote: > > > Won't we need to make sure the socket options SO_SNDBUF and SO_RCVBUF > fit > > > MTU? Doing a UDP sendto, for example can cause an EMSGSIZE if the > message > > > is longer than SO_SNDBUF. > > > > > > --Nick > > > > > > On Wed, Aug 4, 2010 at 10:07 PM, Varun Chandramohan < > > > *var...@linux.vnet.ibm.com* <var...@linux.vnet.ibm.com>> wrote: > > > > > > > Hi Richard, > > > > > > > > As per the below discussion Venkat had updated the patch. Can you > please > > > > take a look and commit these changes? > > > > > > > > > > > > * > http://sourceforge.net/tracker/?func=detail&aid=3016317&group_id=1730&atid=101730 > *<http://sourceforge.net/tracker/?func=detail&aid=3016317&group_id=1730&atid=101730> > > > > > > > > Regards, > > > > > > > > Varun > > > > > > > > On Thursday, July 08, 2010 02:11:49 pm Morrell Richard (external) > wrote: > > > > > > > > > In the daemon code, I would suggest we store the MTU in the > > > > G_SlpdProperty > > > > > > > > > structure when the config file is read or re-read (as in Venkat > Puvvada's > > > > > > > > > patch), and replace all references to SLPD_MAX_DATAGRAM_SIZE by > > > > > > > > > G_SlpdProperty.MTU throughout the daemon source. > > > > > > > > > > > > > > > > > > In the library code, there is (currently) no global property > structure. > > > > We > > > > > > > > > could introduce one, expanding libslp_property.c to initialise it, > or > > > > just > > > > > > > > > initialise a local variable when needed by calling > > > > > > > > > SLPPropertyAsInteger("net.slp.MTU"), and replace the references to > > > > > > > > > SLPD_MAX_DATAGRAM_SIZE by a reference to the local variable (as is > > > > partially > > > > > > > > > done in libslp_network.c). > > > > > > > > > > > > > > > > > > The SLPD_MAX_DATAGRAM_SIZE macro should also be removed. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Varun Chandramohan > > > > > [mailto:*var...@linux.vnet.ibm.com*<var...@linux.vnet.ibm.com> > ] > > > > > > > > > Sent: 08 July 2010 09:17 > > > > > > > > > To: Morrell Richard (external) > > > > > > > > > Cc: > > > > > '*openslp-de...@lists.sourceforge.net*<openslp-devel@lists.sourceforge.net>'; > *liwei...@cn.ibm.com* <liwei...@cn.ibm.com>; > > > > > > > > > *viksa...@in.ibm.com* <viksa...@in.ibm.com>; > > > > > *vpuvv...@in.ibm.com*<vpuvv...@in.ibm.com> > > > > > > > > > Subject: Re: Regd: Openslp MTU issue > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree, we need a better solution to the problem,i think Venkatesh > got > > > > it > > > > > > > > > right, but its not done fully. May be if you can point out the > possible > > > > > > > > > solution you are looking for, he might be able to redo > > > > > > > > > the patch and submit. > > > > > > > > > > > > > > > > > > Wei Wei, Venkateswara, and Vikram can you guys discuss here and > take it > > > > > > > > > forward? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Varun > > > > > > > > > On Thursday, July 08, 2010 01:19:57 pm Morrell Richard (external) > wrote: > > > > > > > > > > Yes, we had a project that was registering CORBA IORs that ran to > over > > > > > > > > > 3000 > > > > > > > > > > bytes, and had a similar problem. > > > > > > > > > > > > > > > > > > > > Someone suggested, as a "quick fix" that we change the > > > > > > > > > SLP_MAX_DATAGRAM_SIZE > > > > > > > > > > macro as follows: > > > > > > > > > > #define SLP_MAX_DATAGRAM_SIZE SLPPropertyAsInteger("net.slp.MTU") > > > > > > > > > > so we could control the MTU via the config file. > > > > > > > > > > > > > > > > > > > > As the macro is never used in a compile-time only context (eg. as > the > > > > size > > > > > > > > > > of an array), and the SLPPropertyAsInteger call works in both the > > > > client > > > > > > > > > > library and the daemon code, this worked for that situation. > However, I > > > > > > > > > > wasn't happy about it in a general sense, so I didn't make the > change > > > > in > > > > > > > > > the > > > > > > > > > > OpenSLP code (we apply it as a patch when building). I haven't > had the > > > > > > > > > time > > > > > > > > > > to do a proper job along the lines of that proposed by Venkat > Puvvada > > > > (but > > > > > > > > > > extended to cover all the references to SLP_MAX_DATAGRAM_SIZE in > both > > > > > > > > > daemon > > > > > > > > > > and library code). > > > > > > > > > > > > > > > > > > > > We would certainly support such a fix. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Richard Morrell > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Varun Chandramohan > > > > > > [mailto:*var...@linux.vnet.ibm.com*<var...@linux.vnet.ibm.com> > ] > > > > > > > > > > Sent: 07 July 2010 20:59 > > > > > > > > > > To: Morrell Richard (external) > > > > > > > > > > Cc: > > > > > > '*openslp-de...@lists.sourceforge.net*<openslp-devel@lists.sourceforge.net>'; > John Calcote > > > > > > > > > > Subject: Fwd: Re: Regd: Openslp MTU issue > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To take is discussion forward. This sounds like a important issue > to me > > > > > > > > > and > > > > > > > > > > we can work on a fix if the fix currently provided is right > approach. > > > > > > > > > > > > > > > > > > > > Richard, any thoughts? > > > > > > > > > > > > > > > > > > > > This email, including any attachment, is a confidential > communication > > > > > > > > > > intended solely for the use of the individual or entity to whom > it is > > > > > > > > > > addressed. It contains information which is private and may be > > > > proprietary > > > > > > > > > > or covered by legal professional privilege. If you have received > this > > > > > > > > > email > > > > > > > > > > in error, please notify the sender upon receipt, and immediately > delete > > > > it > > > > > > > > > > from your system. > > > > > > > > > > > > > > > > > > > > Anything contained in this email that is not connected with the > > > > businesses > > > > > > > > > > of this company is neither endorsed by nor is the liability of > this > > > > > > > > > company. > > > > > > > > > > > > > > > > > > > > Whilst we have taken reasonable precautions to ensure that any > > > > attachment > > > > > > > > > to > > > > > > > > > > this email has been swept for viruses, we cannot accept liability > for > > > > any > > > > > > > > > > damage sustained as a result of software viruses, and would > advise that > > > > > > > > > you > > > > > > > > > > carry out your own virus checks before opening any attachment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This email, including any attachment, is a confidential > communication > > > > > > > > > intended solely for the use of the individual or entity to whom it > is > > > > > > > > > addressed. It contains information which is private and may be > > > > proprietary > > > > > > > > > or covered by legal professional privilege. If you have received > this > > > > email > > > > > > > > > in error, please notify the sender upon receipt, and immediately > delete > > > > it > > > > > > > > > from your system. > > > > > > > > > > > > > > > > > > Anything contained in this email that is not connected with the > > > > businesses > > > > > > > > > of this company is neither endorsed by nor is the liability of this > > > > company. > > > > > > > > > > > > > > > > > > Whilst we have taken reasonable precautions to ensure that any > attachment > > > > to > > > > > > > > > this email has been swept for viruses, we cannot accept liability > for any > > > > > > > > > damage sustained as a result of software viruses, and would advise > that > > > > you > > > > > > > > > carry out your own virus checks before opening any attachment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > This SF.net email is sponsored by Sprint > > > > > > > > > What will you do first with EVO, the first 4G phone? > > > > > > > > > Visit *sprint.com/first* <http://sprint.com/first> -- * > http://p.sf.net/sfu/sprint-com-first*<http://p.sf.net/sfu/sprint-com-first> > > > > > > > > > _______________________________________________ > > > > > > > > > Openslp-devel mailing list > > > > > > > > > *openslp-de...@lists.sourceforge.net*<Openslp-devel@lists.sourceforge.net> > > > > > > > > > *https://lists.sourceforge.net/lists/listinfo/openslp-devel*<https://lists.sourceforge.net/lists/listinfo/openslp-devel> > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > The Palm PDK Hot Apps Program offers developers who use the > > > > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > > > > of $1 Million in cash or HP Products. Visit us here for more details: > > > > *http://p.sf.net/sfu/dev2dev-palm*<http://p.sf.net/sfu/dev2dev-palm> > > > > _______________________________________________ > > > > Openslp-devel mailing list > > > > *openslp-de...@lists.sourceforge.net*<Openslp-devel@lists.sourceforge.net> > > > > *https://lists.sourceforge.net/lists/listinfo/openslp-devel*<https://lists.sourceforge.net/lists/listinfo/openslp-devel> > > > > > > > > > > > > > > >
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Openslp-devel mailing list Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
