Open GoogleCodeExporter opened 9 years ago
Original comment by peerbloc...@gmail.com
on 24 Jul 2009 at 5:48
Original comment by peerbloc...@gmail.com
on 24 Jul 2009 at 5:51
Removing 'After1.0' release-targetting.
Original comment by peerbloc...@gmail.com
on 29 Sep 2009 at 3:58
Original comment by peerbloc...@gmail.com
on 30 Sep 2009 at 4:34
Issue 216 has been merged into this issue.
Original comment by peerbloc...@gmail.com
on 1 Dec 2009 at 4:46
Don't know how I didn't catch this one.
Anyways, how would it take up so much more memory? You're already reading
"Range"
(a.k.a. block name), is it that much more to have it grab the list name at the
same
time?
Original comment by brent.ne...@gmail.com
on 2 Dec 2009 at 5:59
Sorry, that was actually stream-of-consciousness writing on my part I think. My
initial concern was that we'd be keeping an extra string in memory at all
times, for
each range present in each of the blocklists you have activated. Then I
realized
that it probably wouldn't be so bad, since we'd likely just store a string
table with
one entry for each list-name, and then with each range just store a byte or two
worth
of an index into that list.
It's currently targetted for PeerBlock 1.1, so it should be going into the Beta
Release train sometime within the next month or two.
Original comment by peerbloc...@gmail.com
on 2 Dec 2009 at 6:18
Issue 241 has been merged into this issue.
Original comment by peerbloc...@gmail.com
on 20 Jan 2010 at 12:00
This is far and away my favorite enhancement I have seen yet. My only addendum
would
be if there were some way to not only see which rule is blocking the IP, but
also to
allow the entire IP range from the main screen without having to go into the
list
manager (Sorry if this part is under another thread...I couldn't find it).
Seriously,
I would LOVE to have this option. Even if it doubled the footprint on my hard
drive
it would still be worth it.
Original comment by Trinity....@gmail.com
on 5 Mar 2010 at 5:58
Sorry I didn't spot this one.
I just submitted a duplicate, issue 300.
This would be a great feature.
I'm not sure about listing the range though I mean it wouldn't hurt of course.
But I'd end up checking the list anyway.
Their could be more that one entry for the same thing.
I'd want to get them all, for example:
Site 1 68.100.200.1 - 68.100.200.4
Site 1 68.100.200.10 - 68.100.200.10
Thanks,
Kenny
Original comment by kenny...@gmail.com
on 9 Apr 2010 at 6:50
Issue 318 has been merged into this issue.
Original comment by peerbloc...@gmail.com
on 20 May 2010 at 3:00
Has this feature been added?
I see that it was meant to be added to the beta soon:
"It's currently targetted for PeerBlock 1.1, so it should be going into the Beta
Release train sometime within the next month or two."
I downloaded 1.0+ (r320) for this feature and it doesnt seem to be there.
Has it not been added to the beta yet?
thanks
Martin
Original comment by j0hnw3...@googlemail.com
on 25 May 2010 at 4:57
It's not implemented yet.
Original comment by XhmikosR
on 30 May 2010 at 11:56
Issue 300 has been merged into this issue.
Original comment by nightstalkerz
on 29 Jul 2010 at 9:31
This would be a great improvement to PB. Like to see this implemented soon. The
memory issues not a biggie sense most user now have 4 to 6 gigs.
Original comment by robrpatt...@gmail.com
on 4 Aug 2010 at 2:16
I would also like to see this implemented. I can't see that assigning a "rule
number" to each item would use that much more memory, but either way, perhaps
the feature could be enabled/disabled at the user's preference.
Additionally, I'd really like to see this feature added to the log file. A
"rule number" (i.e. pointer) may not work in this case unless PB assigns unique
IDs to every rule set ever created on the host machine (which is an option if
using at least 4-byte IDs). However, for log files, it may be better to simply
put the filename of the list in question. It may also be useful to inclue unix
datestamp of the file's modification time, in case a list changes over time.
Again, these features could also be enabled/disabled at the user's preference.
Thank you for your consideration. I hope to see this soon.
Original comment by JinxD...@gmail.com
on 11 Jan 2011 at 1:45
@robrpatt: I suspect your sample might be a bit biased. Never take memory for
granted.
Original comment by wearenot...@gmail.com
on 14 Aug 2012 at 10:46
Original issue reported on code.google.com by
peerbloc...@gmail.com
on 13 Jul 2009 at 4:23