On Thu, Feb 28, 2013 at 6:34 AM, Karsten Loesing wrote:
> [Nick, can you merge my torspec proposal218 branch, please? Thanks!]
>
Done.
yrs,
--
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/lis
[Nick, can you merge my torspec proposal218 branch, please? Thanks!]
On 2/28/13 2:08 AM, Rob Jansen wrote:
> On Mon, Feb 25, 2013 at 10:28 AM, Karsten Loesing
> wrote:
>
>> On 2/23/13 11:20 PM, Rob Jansen wrote:
>>> On Feb 23, 2013 4:22 PM, "Karsten Loesing"
>> wrote:
Your understanding
On 2/23/13 11:20 PM, Rob Jansen wrote:
> On Feb 23, 2013 4:22 PM, "Karsten Loesing" wrote:
>> Your understanding of n_circ_id and p_circ_id matches mine, but are you
>> sure there's a UID for circuits other than origin circuits? I think you
>> mean origin_circuit_t->global_identifier. But there'
On 2/22/13 8:50 PM, Rob Jansen wrote:
> On Fri, Feb 22, 2013 at 12:59 PM, Karsten Loesing
> wrote:
> [...]
>
>> If anything here sounds strange to you, please let me know. I'm not
>> 100% certain that this is the best approach to track circuits from
>> client to exit, or if it's even correct.
>>
On 2/22/13 5:36 PM, Rob Jansen wrote:
> On Tue, Feb 19, 2013 at 10:20 AM, Karsten Loesing
> wrote:
>
>> On 2/12/13 4:54 PM, Damian Johnson wrote:
AppWard and ExitWard indicate the direction of cell flow through the
circuit. Previous cell events aggregated statistics for both directions
Gotcha. I'd still advise against it. Controllers can certainly parse
that kind of response, but it sucks for users. Stem's ORCONN event
handling is suckier than most because of it.
https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/response/events.py#l631
__
On 2/20/13 5:13 PM, Damian Johnson wrote:
>> In general, I agree. Here, I re-used the code that adds a LongName or
>> Target to CIRC events. It's a single function call that returns the
>> best information tor has about the remote end of a connection.
>
> I'm not sure that I follow. Do you mean
> In general, I agree. Here, I re-used the code that adds a LongName or
> Target to CIRC events. It's a single function call that returns the
> best information tor has about the remote end of a connection.
I'm not sure that I follow. Do you mean the Path attribute of CIRC
events? If so then tha
On 2/19/13 5:45 PM, Damian Johnson wrote:
>> I think we should add two more fields
>> InboundName and OutboundName to CELL_STATS events. These fields would
>> contain LongName ($CC88FB3B78599580F1EE4F6F73E26A7EC3DF2CA1~tokenconn)
>> or Target (like 60.1.0.0:10002) of the previous or next node in a
> I think we should add two more fields
> InboundName and OutboundName to CELL_STATS events. These fields would
> contain LongName ($CC88FB3B78599580F1EE4F6F73E26A7EC3DF2CA1~tokenconn)
> or Target (like 60.1.0.0:10002) of the previous or next node in a
> circuit.
Maybe it would make more sense to
On 2/12/13 4:54 PM, Damian Johnson wrote:
>> AppWard and ExitWard indicate the direction of cell flow through the
>> circuit. Previous cell events aggregated statistics for both directions and
>> therefore did not capture information which I believe may be important.
>> These are much more informat
> AppWard and ExitWard indicate the direction of cell flow through the
> circuit. Previous cell events aggregated statistics for both directions and
> therefore did not capture information which I believe may be important.
> These are much more informative than N and P. Do you have suggestions for
> But I wonder why we would
> handle CellType differently and not turn that into an enumeration, too.
Certainly could. I left the CellType alone (both leaving it as
lowercase and a string definition) because it's a sub-mapping and
hence we don't have any precedent for those. On reflection I agree
On 2/11/13 5:37 PM, Damian Johnson wrote:
>> Sure. Please find the revised proposal in branch proposal218 of my
>> public torspec repository:
>>
>> https://gitweb.torproject.org/user/karsten/torspec.git/shortlog/refs/heads/proposal218
>
> Hi Karsten. Looks good! Pushed some revisions to my propos
> Sure. Please find the revised proposal in branch proposal218 of my
> public torspec repository:
>
> https://gitweb.torproject.org/user/karsten/torspec.git/shortlog/refs/heads/proposal218
Hi Karsten. Looks good! Pushed some revisions to my proposal218 branch...
https://gitweb.torproject.org/use
On Mon, Feb 11, 2013 at 9:38 AM, Karsten Loesing wrote:
[...]
> Sure. Please find the revised proposal in branch proposal218 of my
> public torspec repository:
>
> https://gitweb.torproject.org/user/karsten/torspec.git/shortlog/refs/heads/proposal218
>
Merged into torspec master.
__
On Mon, Feb 11, 2013 at 3:35 PM, meejah wrote:
>
> I haven't looked at everything in proposal 218, but I would suggest
> maybe splitting the CELL_STATS into CELL_STATS_LOCAL and
> CELL_STATS_NETWORK:
>
> "650" SP "CELL_STATS_NETWORK" SP
> CircID SP ConnID SP Added SP Removed SP
On Sun, Feb 10, 2013 at 7:08 AM, Andreas Krey wrote:
> On Sat, 09 Feb 2013 14:27:33 +, Damian Johnson wrote:
> ...
>> I cringe a bit to suggest it, but maybe a mapping in a mapping?
>>
>> CELL_STATS PCircID=8 PConnID=47110 PAdded=created:1,relay:1
>> PRemoved=created:1,relay:1
>
> You can as w
On Sat, Feb 9, 2013 at 11:27 PM, Damian Johnson wrote:
>> I wonder if we should avoid restricting connection types in the spec by
>> defining this argument as connection type _string_ as opposed to an
>> enumeration.
>
> That depends on how volatile you think it'll be. If it's reasonably
> static
I haven't looked at everything in proposal 218, but I would suggest
maybe splitting the CELL_STATS into CELL_STATS_LOCAL and
CELL_STATS_NETWORK:
"650" SP "CELL_STATS_NETWORK" SP
CircID SP ConnID SP Added SP Removed SP Time CRLF
"650" SP "CELL_STATS_LOCAL" SP
On Sat, 09 Feb 2013 14:27:33 +, Damian Johnson wrote:
...
> I cringe a bit to suggest it, but maybe a mapping in a mapping?
>
> CELL_STATS PCircID=8 PConnID=47110 PAdded=created:1,relay:1
> PRemoved=created:1,relay:1
You can as well go wild and use recursive syntax:
CELL_STATS PCircID=8 P
> I wonder if we should avoid restricting connection types in the spec by
> defining this argument as connection type _string_ as opposed to an
> enumeration.
That depends on how volatile you think it'll be. If it's reasonably
static then an enumeration would probably be best.
> Has the advantage
On 2/7/13 5:45 PM, Nick Mathewson wrote:
> On Wed, Feb 6, 2013 at 11:14 AM, Karsten Loesing
> wrote:
>> Hi everyone,
>>
>> here's a proposal that defines three new controller events for the
>> TestingTorNetwork mode that shall help us better understand connection
>> and circuit usage in private T
Hi Damian!
Thanks a lot for your feedback! The proposed event formats are not at
all set in stone. If we can change formats to make events easier to
parse, by all means let's do that. You probably have more experience
with the control port than anyone at Tor, so I say let's listen to you.
On 2
Hi Karsten. Looks good to me, just a few comments on the spec parts...
> 5.1. Adding an ID field to ORCONN events
Please define the format of ConnId. This would belong in section 2.4,
expanding...
; Unique identifiers for streams or circuits. Currently, Tor only
; uses digits, but this may chan
On Wed, Feb 6, 2013 at 11:14 AM, Karsten Loesing wrote:
> Hi everyone,
>
> here's a proposal that defines three new controller events for the
> TestingTorNetwork mode that shall help us better understand connection
> and circuit usage in private Tor networks with the goal to make
> simulations mor
Hi everyone,
here's a proposal that defines three new controller events for the
TestingTorNetwork mode that shall help us better understand connection
and circuit usage in private Tor networks with the goal to make
simulations more accurate.
And there's also code:
https://gitweb.torproject.org/k
27 matches
Mail list logo
