Hi,

Here is a patch to add RFC 3768 SSM Multicast support to low-level
Python socket module as of 2.5.1.

I have not tested the setsourcefilter()/getsourcefilter() socket member
functions other than compiling the patch on a Gentoo Linux 2008.0 box
w/2.6 Linux kernel.

These APIs should be fairly portable. Note that I haven't added any
other configure glue, like the rest of socket, support is very low level
and getting the arguments to struct.pack() right is the user's problem.

cheers
BMS

Can you submit a patch against the trunk? There aren't going to be any
new features in 2.5.

Benjamin Peterson wrote:
> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> Can you submit a patch against the trunk? There aren't going to be any
> new features in 2.5.
>   

Would a patch against 2.6a2 be OK?

I have had a lot of problems building Python on Gentoo Linux (where I 
developed these patches) w/o using their ebuild system, so I am trying 
to keep things simple.

This stuff isn't really new as such, it's been in Windows, OpenSolaris 
and other OSes for a while now -- and trying to get FreeBSD SSM support 
out the door. I can understand if folk don't want to incorporate it in 
the production releases which most people are using, though, however 
it's still important that it sees the light of day.

Unfortunately the setsourcefilter() APIs are not terribly accessible to 
non C users such as Python without the wrapping, otherwise we end up 
instantiating arrays like we have to for fcntl.ioctl().

Also the plat-linux2 stuff seems to be lagging w.r.t the glibc inet 
defines in IN.py, where much of this stuff would normally appear.

cheers
BMS

Bruce M Simpson wrote:
> Benjamin Peterson wrote:
>> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>>
>> Can you submit a patch against the trunk? There aren't going to be any
>> new features in 2.5.
>>   
>
> Would a patch against 2.6a2 be OK?
>
> I have had a lot of problems building Python on Gentoo Linux (where I 
> developed these patches) w/o using their ebuild system, so I am trying 
> to keep things simple. 

I just tried to build python 2.6a2 from svn trunk in FreeBSD 
6.3-RELEASE. I get the same error messages as I do in Gentoo Linux:

%%%
Could not find platform independent libraries <prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in <module>
    import sys, os, imp, re, optparse
ImportError: No module named os
gmake: *** [sharedmods] Error 1
Exit 2
%%%

I have no PYTHON* variables set in my environment.

On Gentoo, when I build using the ebuild / emerge system, I don't see 
this issue, nor do I see it with FreeBSD ports. Obviously they are doing 
something which differs from the instructions in the README, and it 
makes it difficult for me to submit patches for versions of Python other 
than those supported by the packaging systems, as I am sure you can 
understand.

cheers
BMS

Ok, we'll see what we can do.

I tried applying this patch to a clean SVN checkout of the 2.6 trunk on
an OS X Leopard machine and it works (except for the part which patches
configure.in).  I then built the source tree and ran the test_socket
test, which also worked fine.  I don't see any tests for the specific
functionality in the patch, or any patch to the documentation of the
socket module.

Bill Janssen wrote:
> Bill Janssen <bill.janssen@gmail.com> added the comment:
>
> I tried applying this patch to a clean SVN checkout of the 2.6 trunk on
> an OS X Leopard machine and it works (except for the part which patches
> configure.in).  I then built the source tree and ran the test_socket
> test, which also worked fine.  I don't see any tests for the specific
> functionality in the patch, or any patch to the documentation of the
> socket module.
>   

Good to hear of your build success on OS X, don't know about 
configure.in off the top of my had.

Exercising the API fully requires an SSM capable multicast LAN.

It's been a few months, as far as I can remember I did add the ssm 
methods and arguments to the built-in documentation for the socket object?

On Wed, Sep 17, 2008 at 10:45 AM, bms <report@bugs.python.org> wrote:

>
> Exercising the API fully requires an SSM capable multicast LAN.
>

Let's hope the PARC network is still up-to-date.  It was when we were
developing multicast here some 15-20 years ago :-).

Bill

>
> Exercising the API fully requires an SSM capable multicast LAN.

... and it also requires a host IP stack implementing the API, which is
not yet (AFAIK) the case for Mac OS X, even very recent releases.

I think you will need a Windows or Linux box to successfully run a tests
that uses RFC3768 functions/consts.

I've applied the patch to the release26-maint branch, and I was able to
properly compile, run and do some basic testing of the result.

Find attached a patch applying cleanly to SVN release26-maint branch.

Looks as if the status was inadvertently set to languishing.  Stage needs setting to patch review.  The patch is effectively all new C code but there are no doc changes or tests.