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
