[prev in list] [next in list] [prev in thread] [next in thread]
List: privoxy-developers
Subject: [privoxy-devel] [ ijbswa-Patches-3354485 ] Multiple listen-address
From: "SourceForge.net" <noreply () sourceforge ! net>
Date: 2011-07-19 10:38:41
Message-ID: E1Qj7hK-0003sW-QB () sfs-ml-3 ! v29 ! ch3 ! sourceforge ! com
[Download RAW message or body]
Patches item #3354485, was opened at 2011-07-05 18:36
Message generated for change (Comment added) made by fabiankeil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=311118&aid=3354485&group_id=11118
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: new feature
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Petr Písař (petrp)
Assigned to: Fabian Keil (fabiankeil)
Summary: Multiple listen-address implementation
Initial Comment:
Hello,
I found some operating systems does not allow to accept IPv4 client on IPv6 sockets \
or some system are configured in such manner (like GNU/Debian). Also I think it can \
be helpful to bind Privoxy to certain addresses only or to more ports.
There is similar item #71 on TODO list. My implementation forces to bind to all \
listed addresses. However it could be possible to adjust it.
I performed only few tests so there can be some bugs.
I will attach series of 5 patches against latest CVS tree.
----------------------------------------------------------------------
> Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-19 10:38
Message:
I just removed #71 from the TODO list, and now realize that I worded it
poorly which allowed an unintended interpretation.
By "without having to bind to all" I was referring to the workaround of
using "listen-address :8118" to let Privoxy bind to all the addresses
available on the system, not that Privoxy should allow multiple
listen-address directives and ignore bind failures.
As far as I'm concerned #71 has been implemented completely.
----------------------------------------------------------------------
Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-17 13:46
Message:
Patches 0001 to 0007 have been squashed and committed.
0008 has been committed separately.
----------------------------------------------------------------------
Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-14 21:09
Message:
Looks like I forgot the "config->need_bind = 0;" at either the beginning or
the end of the function ...
----------------------------------------------------------------------
Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-14 20:40
Message:
Thanks for the additional patches.
I think with the current bind_port_helper() behavior, bind_ports_helper()
can be further simplified to:
{
int i;
for (i = 0; i < MAX_LISTENING_SOCKETS; i++)
{
if (config->hport[i])
{
sockets[i] = bind_port_helper(config->haddr[i],
config->hport[i]);
}
else
{
sockets[i] = JB_INVALID_SOCKET;
}
}
}
(I already have a patch for this and intend to commit it separately)
----------------------------------------------------------------------
Comment By: Petr Písař (petrp)
Date: 2011-07-13 19:53
Message:
Ok, patch 0007-Drop-need_bind-flag-once-any-socket-binds.patch fixes the
typo in condition in bind_ports_helper(), patch
0008-Log-listening-on-socket-after-binding.patch moves the `Listening on
port...' log message after actual binding as you pointed in last post.
----------------------------------------------------------------------
Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-12 18:47
Message:
Trying once per address seems to be enough to me.
I don't consider it a problem to treat bind failures as fatal issues.
Until TODO list items #22 and #23 are implemented I'd actually consider it
the best option.
The problem I see with #2 is that if bind_port_helper() wouldn't die and
if the user specified an address twice (or just used an incorrect one)
Privoxy would waste a lot of time trying to bind to it again and again.
While we could limit the attempts, I think that would be more magic than
necessary and it also wouldn't be consistent with the behavior in case of
other configuration issues.
Looking at bind_port_helper() some more, I also think it shouldn't log the
"Listening on ..." messages unless binding to the address actually worked.
I'm aware that it already does that without your patch, though.
----------------------------------------------------------------------
Comment By: Petr Písař (petrp)
Date: 2011-07-11 18:01
Message:
You are right. Current code does not make sense. Correct fix depends on
semantics you want to give to bind_ports_helper():
(1) If you want to drop not-bound sockets and survive with successfully
opened ones, your suggestion is correct.
(2) If you want to leave possibility to re-bound on next loop cycle, one
should pre-set config->need_bind to 0, keep the condition and change
conditional assignment to setting 1.
The only drawback is current bind_port_helper(), that's called from
bind_ports_helper(), dies on any error, thus resolving given problem is
just an academic question.
I think choosing solution (2) opens way for implementing TODO item #71
more comprehensively. So I vote for it. Actually current implementation
dies on reloading wrong configuration which I don't like. I think the
daemon, once started, should keep running as long as possible.
----------------------------------------------------------------------
Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-10 10:07
Message:
I think there may be a logical error in bind_ports_helper().
+ if (JB_INVALID_SOCKET == sockets[i])
+ {
+ config->need_bind = 0;
+ }
Shouldn't the condition be JB_INVALID_SOCKET != sockets[i] here?
----------------------------------------------------------------------
Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-06 17:53
Message:
Thanks a lot for the patches.
I'll have a closer look at them this weekend.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=311118&aid=3354485&group_id=11118
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Ijbswa-developers mailing list
Ijbswa-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ijbswa-developers
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic