On Wednesday, July 07, 2010 07:07:42 pm Morrell Richard (external) wrote: > Hi Varun, > > According to the forum post, the reason the socket removal code was > commented out in the first place was that, prior to this call, the slp.reg > file had been processed, which, for IPv6, created multicast sockets for each > of the static registrations. They were then deleted by this code. > > Do you have any static registrations in your slp.reg file ? If not, then > you won't have seen this problem. > Yes i dont have static registrations. I understand the reason now. > My original concern regarding running the code as a result of SIGHUP was > theoretical, in that I hadn't had the time to investigate it myself. > Searching the latest trunk code for calls to SLPDIncomingInit, I can only > find one call in slpd_main.c and one in slpd_win32.c. > > The call in slpd_main.c is only made once, on startup, so there would be no > detrimental effect in commenting out the socket removal code in this case, > as the socket list is statically initialised to empty. > > The call in slpd_win32.c is made from the ServiceStart() function, and, > although I don't know that much about Windows services, it looks like the > sockets will be removed after a ServiceStop call, so there should be no need > to clean up the list on the next ServiceStart call, even if sockets were > persistent between ServiceStop and ServiceStart calls. > > In other words, it now looks to me that we should apply the patch as it > stands (given that you have been testing with both IPv4 and IPv6 enabled > with no problems), including commenting out the socket removal code. Did > your investigations find anything that invalidates my analysis above ? > I agree with your investigations. Please go ahead and apply the change. Lets see if anyone here has any issue. > Regards, > > Richard > > NB. I have copied this to the openslp-devel mailing list in case anyone > there has any comments or insights. > > -----Original Message----- > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com] > Sent: 06 July 2010 10:08 > To: Morrell Richard (external) > Subject: Re: Add IPv6 Fix Support! > > > Hi Morrell, > > I was busy fixing some major ipv6 issues for openslp that i could > not look at this for sometime. Iam sorry. As far the first question is > concerned you are right, it must not be commented. I will fix that. > > Iam not sure what the intention was, but i have been running with both ipv4 > and ipv6 for about 4 months now. I have run slpd as SA and never faced an > issue. As DA i ran for a while, but not very extensively tested. From my > code reading, it seems that code can handle both ipv4 and ipv6 > simultaneously. > > I have tons of fixes that i need to submit, but for that this patch has to > go in. As i have already told you iam not allowed to modify this patch due > to company rules, i will have a patch made on top of latest svn with the > comment change. That patch you can apply or change it yourself. Is that ok > with you? > > Regards, > Varun > > > On Thursday, June 03, 2010 12:37:58 pm you wrote: > > Sorry, Varun, I've been a bit busy recently. > > > > The patch looks relatively straightforward in itself, but I have some > > concerns. > > > > Regarding the commenting out of the removal of sockets, the code is run at > > initialisation, in which case it would seem to be completely redundant, as > > the structure it is apparently clearing is statically initialised to empty > > anyway. If the code could be run at some time other than initialisation, > > however, eg. after a SIGHUP to re-interpret the configuration files, then > we > > may not clear down sockets that we should be clearing down. How sure are > > you that the code is not run at other than first initialisation ? > > > > Secondly, the patch makes it so that IPv4 and IPv6 operation can be > enabled > > independently, whereas the original behaviour was to have one or the > other. > > There may be assumptions in the code that rely on this eg. interpreting > the > > format of IP addresses depending on whether IPv4 is enabled. How much > > testing have you done to make sure that IPv4 operation is not affected > when > > IPv6 operation is enabled ? > > > > -----Original Message----- > > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com] > > Sent: 02 June 2010 07:05 > > To: Morrell Richard (external) > > Subject: Re: Add IPv6 Fix Support! > > > > > > Hi, > > > > Any update on this? Did you get a chance to look? > > > > On Wednesday, May 19, 2010 08:53:53 pm you wrote: > > > Hi Varun, > > > > > > I'm not that familiar with the IPv6 support, but I'll take a look at the > > > patch. > > > > > > Regards, > > > Richard > > > > > > -----Original Message----- > > > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com] > > > Sent: 19 May 2010 06:27 > > > To: Morrell Richard (external) > > > Cc: openslp-devel@lists.sourceforge.net > > > Subject: Add IPv6 Fix Support! > > > > > > > > > Hi Morrell, > > > > > > I have extensively tested the ipv6 fixes submitted long > > > time > > > ago. I found them to be working fine except a few bugs. For those bugs > i > > > already have bug fixes submitted. The patch iam talking about is > > > > > > https://sourceforge.net/mailarchive/forum.php?thread_name=487B7A7B.7070308%4 > > > 0TrustedCS.com&forum_name=openslp- > > > devel > > > > > > As part of my company policy iam not allowed to commit patches that are > > not > > > mine. If its possible can you review the patch and commit patch? If done > i > > > can > > > work on further fixes. Let me know if this can be worked out? > > > > > > Regards, > > > Varun > > > > > > 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 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
