Re: [tor-bugs] #28877 [Core Tor/Tor]: Paginate large controller commands like 'GETINFO desc/all-recent'

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#28877: Paginate large controller commands like 'GETINFO desc/all-recent'
--------------------------+--------------------------
 Reporter:  wagon         |          Owner:  (none)
     Type:  defect        |         Status:  assigned
 Priority:  Medium        |      Milestone:
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+--------------------------

Comment (by wagon):

 > Do you have a SSD?

 > I suspect this might be a matter of disk iops.
 No, I don't have SSD. However, disk cache should work (further invocations
 of the same commands are faster than the first ones, I think it is because
 of disk cache). Now I cannot make an ideal test with the whole system
 residing in RAM, but I copied Nyx/Stem directory to /tmp (which resides in
 RAM) and compared it with my above initial tests. I didn't find any
 difference. Shell is still at least two times faster than `tor-prompt`.

 > Again, this command is reading fourteen megabytes of data from disk then
 dumping it on the socket.
 I thought this data is read from memory of tor process, i.e. from RAM. Are
 you sure Tor makes request to hard drive each time it needs to provide
 this data?

 > get ran in low resource environments (arduino and such) where such
 commands can easily block the control connection for tens of seconds to
 minutes.
 Do you think it also explains the crash of `tor-prompt --run 'GETINFO desc
 /all-recent >/dev/null` command?

 If pipe is used, shell will also break (this is the reason I had to use
 descriptors in `test.sh`). For example, success of the command
 {{{
 ( echo AUTHENTICATE \"pass\" ; echo GETINFO ns/all ; echo QUIT ) | nc
 127.0.0.1 9051
 }}}
 depends on the time of invocation, existence of redirection to some file
 or to `/dev/null`, weather, and so on. If I redirect the output of this
 command to some file in RAM, I see that it stops after roughly 20k lines
 are printed. However, it works nice with short output commands.

 > these commands are no-gos if distributing an application more broadly.
 I agree. Let us wait what Tor core people will say.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28877#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs