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
