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> > 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> 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 > > > > > > > > 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] > > > > > > > > > Sent: 08 July 2010 09:17 > > > > > > > > > To: Morrell Richard (external) > > > > > > > > > Cc: 'openslp-devel@lists.sourceforge.net'; liwei...@cn.ibm.com; > > > > > > > > > viksa...@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] > > > > > > > > > > Sent: 07 July 2010 20:59 > > > > > > > > > > To: Morrell Richard (external) > > > > > > > > > > Cc: '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://p.sf.net/sfu/sprint-com-first > > > > > > > > > _______________________________________________ > > > > > > > > > Openslp-devel mailing list > > > > > > > > > Openslp-devel@lists.sourceforge.net > > > > > > > > > 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 > > > > _______________________________________________ > > > > Openslp-devel mailing list > > > > Openslp-devel@lists.sourceforge.net > > > > 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
