On Sat, 10 Jan 2009, Julian Elischer wrote:
I'm happy to (eventually) also implement the BSDI API once I actually
spend time looking at what the difference in behaviours are. If we're
lucky, the only difference is where the socket option hooks in and the
actual network behaviour is the same.
Attila Nagy wrote:
...
Do you know anything else which can do that now with an easy API
(accessible from high level languages like perl or python)?
I sent a patch to the Python guys to implement the protocol-independent
multicast socket API a good while back. It takes a long time to get
feed
Robert Watson wrote:
On Sat, 10 Jan 2009, Adrian Chadd wrote:
2009/1/10 Robert Watson :
I think Julian's analysis, that this is more of an inet option than a
socket-layer option, seems more appropriate to me, the benefits of
portability in adopting the API used by OpenBSD/BSDI/etc seem more
2009/1/10 Robert Watson :
> If the API turns out to be effectly semantically the same, or better, then I
> think the suggestion is to entirely replace, rather than supplement, the
> socket option you just added with it. There's no point in having
> pointlessly divergent APIs where it can be avoid
On Sat, 10 Jan 2009, Adrian Chadd wrote:
2009/1/10 Robert Watson :
I think Julian's analysis, that this is more of an inet option than a
socket-layer option, seems more appropriate to me, the benefits of
portability in adopting the API used by OpenBSD/BSDI/etc seem more
compelling. We shou
Adrian Chadd wrote:
2009/1/10 Attila Nagy :
BTW, I'm eagerly waiting for somebody to implement this transparency into
nginx, which can act as a reverse proxy with built-in perl logic. :)
That way FreeBSD could be used as a highly flexible transparent reverse HTTP
proxy.
Do you know anything e
2009/1/10 Attila Nagy :
> BTW, I'm eagerly waiting for somebody to implement this transparency into
> nginx, which can act as a reverse proxy with built-in perl logic. :)
> That way FreeBSD could be used as a highly flexible transparent reverse HTTP
> proxy.
>
> Do you know anything else which ca
Adrian Chadd wrote:
2009/1/10 Robert Watson :
I think Julian's analysis, that this is more of an inet option than a
socket-layer option, seems more appropriate to me, the benefits of
portability in adopting the API used by OpenBSD/BSDI/etc seem more
compelling. We should make sure that, if we
On Jan 10, 2009, at 10:28, Attila Nagy wrote:
Adrian Chadd wrote:
2009/1/10 Robert Watson :
I think Julian's analysis, that this is more of an inet option
than a
socket-layer option, seems more appropriate to me, the benefits of
portability in adopting the API used by OpenBSD/BSDI/etc see
Adrian Chadd wrote:
2009/1/10 Robert Watson :
I think Julian's analysis, that this is more of an inet option than a
socket-layer option, seems more appropriate to me, the benefits of
portability in adopting the API used by OpenBSD/BSDI/etc seem more
compelling. We should make sure that, if
2009/1/10 Robert Watson :
> I think Julian's analysis, that this is more of an inet option than a
> socket-layer option, seems more appropriate to me, the benefits of
> portability in adopting the API used by OpenBSD/BSDI/etc seem more
> compelling. We should make sure that, if we move to the soc
On Sat, 10 Jan 2009, Attila Nagy wrote:
Well, they can be used mostly interchangably - they socket option is just
implemented at a different layer.
Porting should be a case of a simple #ifdef. :)
I wonder what pf changes are needed..
I think Julian's analysis, that this is more of an inet
Hello,
pf and relayd changes...
http://marc.info/?l=openbsd-cvs&m=121030115209292&w=2
http://marc.info/?l=openbsd-cvs&m=121320866832670&w=2
(sorry, I don't know a better way to link to these changes, the commit
logs contain the affected files and their log message, so they can be
looked up in t
Adrian Chadd wrote:
I wasn't even aware of the existance of this interface. I'll check it out.
Thing is, this is a socket layer option, rather than what I've
committed which is a netinet layer option.
Anyway, I'll check it out. I'm happy to fiddle with things if others'
would like it.
remember
Well, they can be used mostly interchangably - they socket option is
just implemented at a different layer.
Porting should be a case of a simple #ifdef. :)
I wonder what pf changes are needed..
Adrian
2009/1/9 Attila Nagy :
> Julian Elischer wrote:
>>
>> Attila Nagy wrote:
>>>
>>> Hello,
>>>
>
Julian Elischer wrote:
Attila Nagy wrote:
Hello,
Adrian Chadd wrote:
Author: adrian
Date: Fri Jan 9 16:02:19 2009
New Revision: 186955
URL: http://svn.freebsd.org/changeset/base/186955
Log:
Implement a new IP option (not compiled/enabled by default) to allow
applications to specify a non
Attila Nagy wrote:
Hello,
Adrian Chadd wrote:
Author: adrian
Date: Fri Jan 9 16:02:19 2009
New Revision: 186955
URL: http://svn.freebsd.org/changeset/base/186955
Log:
Implement a new IP option (not compiled/enabled by default) to allow
applications to specify a non-local IP address when b
I wasn't even aware of the existance of this interface. I'll check it out.
Thing is, this is a socket layer option, rather than what I've
committed which is a netinet layer option.
Anyway, I'll check it out. I'm happy to fiddle with things if others'
would like it.
Adrian
2009/1/9 Attila Nagy
Hello,
Adrian Chadd wrote:
Author: adrian
Date: Fri Jan 9 16:02:19 2009
New Revision: 186955
URL: http://svn.freebsd.org/changeset/base/186955
Log:
Implement a new IP option (not compiled/enabled by default) to allow
applications to specify a non-local IP address when bind()'ing a socket
Robert Watson wrote:
On Fri, 9 Jan 2009, Julian Elischer wrote:
Max Laier wrote:
On Friday 09 January 2009 17:02:19 Adrian Chadd wrote:
Author: adrian Date: Fri Jan 9 16:02:19 2009 New Revision: 186955
URL: http://svn.freebsd.org/changeset/base/186955
Log:
Implement a new IP option (not c
On Friday 09 January 2009 19:29:11 Adrian Chadd wrote:
> 2009/1/9 Max Laier :
> > Speaking of disabling it ... setting the sysctl to 0 is not really enough
> > to do that. One would also have to walk through the active sockets and
> > GC any that are bound to nonlocal addresses to really disable i
On Fri, 9 Jan 2009, Julian Elischer wrote:
Max Laier wrote:
On Friday 09 January 2009 17:02:19 Adrian Chadd wrote:
Author: adrian Date: Fri Jan 9 16:02:19 2009 New Revision: 186955 URL:
http://svn.freebsd.org/changeset/base/186955
Log:
Implement a new IP option (not compiled/enabled by def
2009/1/9 Max Laier :
> Speaking of disabling it ... setting the sysctl to 0 is not really enough to
> do that. One would also have to walk through the active sockets and GC any
> that are bound to nonlocal addresses to really disable it ... or do we rely on
> tcpdrop or the like to do that manual
Max Laier wrote:
On Friday 09 January 2009 18:46:06 Julian Elischer wrote:
Max Laier wrote:
On Friday 09 January 2009 17:02:19 Adrian Chadd wrote:
Author: adrian
Date: Fri Jan 9 16:02:19 2009
New Revision: 186955
URL: http://svn.freebsd.org/changeset/base/186955
Log:
Implement a new IP opt
Max Laier wrote:
On Friday 09 January 2009 17:02:19 Adrian Chadd wrote:
Author: adrian
Date: Fri Jan 9 16:02:19 2009
New Revision: 186955
URL: http://svn.freebsd.org/changeset/base/186955
Log:
Implement a new IP option (not compiled/enabled by default) to allow
applications to specify a no
On Friday 09 January 2009 18:46:06 Julian Elischer wrote:
> Max Laier wrote:
> > On Friday 09 January 2009 17:02:19 Adrian Chadd wrote:
> >> Author: adrian
> >> Date: Fri Jan 9 16:02:19 2009
> >> New Revision: 186955
> >> URL: http://svn.freebsd.org/changeset/base/186955
> >>
> >> Log:
> >> Impl
On Friday 09 January 2009 17:02:19 Adrian Chadd wrote:
> Author: adrian
> Date: Fri Jan 9 16:02:19 2009
> New Revision: 186955
> URL: http://svn.freebsd.org/changeset/base/186955
>
> Log:
> Implement a new IP option (not compiled/enabled by default) to allow
> applications to specify a non-loc
Author: adrian
Date: Fri Jan 9 16:02:19 2009
New Revision: 186955
URL: http://svn.freebsd.org/changeset/base/186955
Log:
Implement a new IP option (not compiled/enabled by default) to allow
applications to specify a non-local IP address when bind()'ing a socket
to a local endpoint.
Thi
28 matches
Mail list logo
