optimising torrenting performance on cryptostorm: discussion

Freewheeling spot to chew the fat on anything cryptostorm-related that doesn't fit elsewhere (i.e. support, howto, &c.). Criticism & praise & brainstorming & requests for explanation... this is where it goes when it's hot & ready for action! :-)
caustic386
Posts: 7
Joined: Sun Nov 17, 2013 1:12 am

optimising torrenting performance on cryptostorm: discussion

Post by caustic386 » Sun Nov 17, 2013 2:15 am

Looking through the forums, I'm a little confused about the status of CS' ability to properly permit torrent traffic. It seems you don't block it, but has it been successfully tested by users?

Guest

Re: Torrents?

Post by Guest » Mon Nov 18, 2013 12:55 pm

Downloading torrents works fine, it takes a while longer for speed to ramp up. Where it falls flat is uploading. Fine for public trackers, but if you are trying to maintain a ratio...good luck.

User avatar
Pattern_Juggled
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: Torrents?

Post by Pattern_Juggled » Tue Nov 19, 2013 1:17 am

I'm glad to see this thread opened up, as we've been seeing quite a bit of "chatter" going across the wire in conversations the support folks are having with network members. I believe there's some of those threads (including one in bitmessage that's been really interesting to follow) that will be migrating to this thread shortly for wider public access, so I'll not muddy the waters with my own ramblings. Too much, anyway.

Cryptostorm is designed and managed to support full-spectrum, full-throughput bittorrent connectivity for all network members. There's no manual port forwarding, as all ports translate across the network, to each client, without manual intervention. This does mean, as a previous poster mentioned, that it takes a few minutes after connection for peers in the swarm (or a tracker, if non-DHT'd) to "find" your BT client with it's cryptostorm-fronted interface... but that's a simple network resource discovery process.

After that, all BT traffic should flow as would any and all other packets, through cryptostorm.

I'm keen to see frontline experiences from other members, but I know several in-house tech team folks have been running torrent apps over the network for many weeks at full throttle, with no hiccups. As I've said elsewhere, it's not necessary to enable UPnP in torrent clients... although anecdotal evidence from some beta testers suggests that setting helps improve torrenting performance in some torrent clients, on some platforms. No, I have no theory to explain this reported behaviour. Black magic.

One thing that's probably a good idea is ensuring that the "default" port for a specific bittorrent client app isn't used, as it's possible that would clog up with other cryptostorm members defaulting to the same port (it should still transit packets, but might have less robust performance and put a much heavier load on the server-side resources). That's also good security policy, to vary port assignments between torrenting sessions.

The entire cryptostorm tech and admin team, going back to the old days of TorrentFreedom, has been 100% supportive of torrenting as a fundamental peer-to-peer technology. We've never hindered such applications on our network - and never will. Indeed, we've tuned aggressively to support them: we were the first "VPN service," in 2008, to deploy UDP as our network protocol specifically in order to improve torrenting bandwidth availability (it worked - now basically everyone runs UDP, save for those too lazy to change the 'default' server.conf file that comes rolled with the default openvpn installation).

Again anecdotally, some internal tech team staffers have pushed consistent 20megabit up/down torrent sessions - with thousands of connected peers, seeding and leeching - for days at a time. There's no structural reason why seeding should be any slower than download performance from the swarm: if that's being seen, it's most assuredly a buggy behavior and the support folks can help resolve it. By no means is it something the network does intentionally!

Several of our staffers have hands-on experience as admins on private trackers themselves, as well as code contributions to various opensource tracker projects. We do our best to stay abreast of the torrenting world, and will always support peer-connection file distribution as a fundamental use-case for cryptostorm's secure network.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f[/color]

User avatar
Graze
Posts: 119
Joined: Mon Dec 17, 2012 2:37 am
Contact:

TorrentFreedom, ca. 2008

Post by Graze » Tue Nov 19, 2013 1:28 am

TorrentFreedom_cuts_Occam.pdf
(515.08 KiB) Downloaded 1897 times
bannerdha7.png
bannerdha7.png (59.09 KiB) Viewed 273411 times
bannerd1yp0.png
bannerd1yp0.png (50.17 KiB) Viewed 273411 times
background.jpg
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)

caustic386
Posts: 7
Joined: Sun Nov 17, 2013 1:12 am

Re: Torrents?

Post by caustic386 » Wed Nov 20, 2013 12:47 am

Pattern_Juggled wrote:Again anecdotally, some internal tech team staffers have pushed consistent 20megabit up/down torrent sessions - with thousands of connected peers, seeding and leeching - for days at a time. There's no structural reason why seeding should be any slower than download performance from the swarm: if that's being seen, it's most assuredly a buggy behavior and the support folks can help resolve it. By no means is it something the network does intentionally!
Excellent news! Looking forward to trying it out once the 70.x.x.x issue is resolved.

cryptostorm_ops

Re: Torrents?

Post by cryptostorm_ops » Fri Dec 20, 2013 8:10 am

caustic386 wrote:forward to trying it out once the 70.x.x.x issue is resolved.
Resolved.

User avatar
Pattern_Juggled
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am
Contact:

session tuning

Post by Pattern_Juggled » Wed Jan 22, 2014 3:50 pm

Along with the rest of the Ops team, I've been doing some iterative work in fine-tuning the various layers of interlocking parameters that govern the transit of packets from member client instances out through the exitnode clusters - from hand-rolled SNAT directives thru ring buffer tweaks, packet queue expansions, and socket resourcing at the kernel level. It's a bit of a jigsaw puzzle as each one impacts the others in nonlinear ways... but it appears that we've made some steady progress in opening up additional performance capacity.

I'm curious as to feedback on how this is playing out in filesharing-intensive use-case scenarios. We have a few test instances that we'll load up with 600+ simultaneous .torrent peers in a collection of concurrent swarms and they seem to produce good results - but those are not enough in number to generalize across all the node clusters out there nowadays.

I hope folks that are pushing the network hard with torrenting challenges will report their results, so we can continue to tune things. In general, it's not terribly complex to support high-throughput for a couple of swarms with lots of fast, stable peers offering up file segments; more challenging are dozens of swarms with poor-quality peers in large numbers, creating hundreds/thousands of open or quasi-open handshakes during operations. The latter has, in past work we've done, resulted in massive socket bottlenecking at the network level, which we've resolved via intensively over-provisioned socket resource pools and, frankly, throwing RAM at the underlying kernel processes. Since then, I know the linux kernel has improved its socket administration considerably - I've seen the metrics firsthand, and they're really impressive - but I don't want to assume it's no longer a bottleneck at all.

tl;dr - feedback appreciated :-)
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f[/color]

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm & bittorrent: perf tuning & tweaks | ONGOING

Post by parityboy » Wed Feb 05, 2014 8:46 pm

I don't have much to offer on this, but what I have I'll share.

I'm currently running Mint 14 KDE in a VM, with the KTorrent client. One of the private trackers I'm active on has "freeleech" running at the moment, so quite a few of my torrents are seeing activity. My line is 8/1 ADSL, and uploads are running at capacity. Downloading the latest Linux Mint 16 via Bit Torrent tops out at just over 1.0MiB/sec.

Additionally, I have disabled the UPnP plugin; the private tracker I use is based on the Gazelle/Ocelot codebase and includes a connectivity checker - it fails miserably since it can no longer make an inbound connection to my torrent client (this worked on the old CC network) but nonetheless I appear to be able to seed back previously downloaded (and uploaded) torrents perfectly well.

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm & bittorrent: perf tuning & tweaks | ONGOING

Post by DesuStrike » Thu Feb 06, 2014 2:57 am

Today I really cranked up my torrents (and still do) and I must report worse performance than what I was used to with config 0.9d around. I know the config has nothing to do with this, it only serves as a time frame.

My connection is capable of pulling down almost 6 Megabytes per second and in the past I was able to get almost full speed with well seeded torrents. Now everything just dangles around 1,2 to 2 MByte/s. I also witnessed how the perfomance broke down to 50 KB/s for some time just do get faster again shortly after. This sounds awfully like those "bursting" issues I read about before.

Same is true for uploads by the way. I can push up around 450 KB/s normally but now it's only getting to around 200KB/s in those "bursting" moments.

What's also strange: Reducing the upload is increasing the download performance and vice versa. I was able to get best perfomances by limiting upload to 50KB/s. (The download numbers above reflect the performance with this setting!) AFAIK you shouldn't max out uploads so you do not block ACK packets but I was never forced to reduce it this much. It's almost as if I overstrain the node with too many traffic in both directions at the same time. I don't know if this makes sense but I just wanted to mention that.

Also noteworthy: It's no simple exit node performance issue. I actually get almost full speed when I do a wget. So this has definitely something to do with the exitnode handling P2P connections. Bitmessage and bitcoin for example can't get a green light at all with CS enabled.
home is where the artillery hits

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm & bittorrent: perf tuning & tweaks | ONGOING

Post by parityboy » Thu Feb 06, 2014 5:21 am

@DesuStrike

Silly question, but is your connection to the Internet symmetrical and full duplex? I ask, because I've only noticed upload and download speeds affecting each other on asymmetrical connections, typically residential cable and xDSL. Also, how many torrents did you have active at a time?

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm & bittorrent: perf tuning & tweaks | ONGOING

Post by DesuStrike » Thu Feb 06, 2014 7:50 am

Asymmetrical. They don't sell symmetrical connections here to "normal" customers...

Different. I had no more than 10 today and all were well seeded. So I don't think I overstrained my connection.

I remember a session in the past where I had way over 30 torrents active at the same time and my speed was excellent.
home is where the artillery hits

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm & bittorrent: perf tuning & tweaks | ONGOING

Post by parityboy » Thu Feb 06, 2014 3:41 pm

@DesuStrike

Thanks for the reply. If possible, it might be worth spinning up a desktop VM (or just a seedbox) right at the edge of the CS infrastructure, loading it up with torrents and seeing how it behaves against expected performance. Another thing to note is that your ISP may be the culprit. Many of them do perform QoS on VPN connections - I know mine does.

User avatar
Pattern_Juggled
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm & bittorrent: perf tuning & tweaks | ONGOING

Post by Pattern_Juggled » Fri Feb 07, 2014 12:08 pm

Although this is a thread for torrent performance-tuning, I wanted to point to a parallel thread that's been opened to discuss perf-tuning more broadly, across the network: viewtopic.php?f=38&t=6083

As can be seen from various posts in this subforum regarding parameter testing and cross-cluster testing of throughput, it's very much a "work in process" to get performance optimized across the board. Indeed, there's some parts of the perf-tuning process that look like - at least without some highly aggressive kernel modifications - they embody intrinsic trade-offs. I suspect that there's one to be found in whether things are primarily optimised for single-socket TCP sessions at high bandwidth, versus widely-spanned UDP connectivity as in a big torrent swarm: the more one is tweaked for maximal throughput, the more the other lags in some regards.

I do know that there's some structural trade-offs between lowered latency, and maximal throughput, for some session parameters: this has to do with packet buffering parameters. Basically, if you turn down all the various layers of packet buffers you tend to get some really good latency metrics... at the cost of consistently fat throughput (and also at the cost of some lost/retransmitted packets). Conversely, beef up the packet buffers and you can generally scale session/socket throughput up to bigger numbers more consistently... but you see some increases in average latency.

Finally, as that other thread discusses in more detail, there's some challenges in "optimising" cryptstorm's architecture for the widely diverse types of inbound connections our members experience: from huge, fast dedicated fiber connection to quite a few members connecting from really high packet-loss rural ISPs. Perf-tuning for one is far different from perf-tuning another, and we're still learning how to provide good throughput to everyone, on average, across the network.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f[/color]

User avatar
Pattern_Juggled
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm & bittorrent: perf tuning & tweaks | ONGOING

Post by Pattern_Juggled » Fri Feb 07, 2014 12:30 pm

DesuStrike wrote:Different. I had no more than 10 today and all were well seeded. So I don't think I overstrained my connection.

I remember a session in the past where I had way over 30 torrents active at the same time and my speed was excellent.
The relevant metric, generally, is number of concurrently-connected peers within one's various torrent swarms.

One may have, for example, a dozen torrents running but each torrent is only engaged in transactions with (random example) 5 peers at a time: that's 60 concurrent sessions. On the flipside, a single torrent might span out to concurrently connect with hundreds of peers (if there's ample local bandwidth and thus the protocol will be comfortable grabbing chunks of the underlying file in parallel from all those peers, at once). Most torrent clients I've seen will allow one to cap the maximum number of concurrent peers; otherwise, it's possible to have thousands of concurrent "sessions" even with idle peers, and this can shut down many standard residential routers as they try to NAT all these connections (usually it overflows router RAM and brings throughput to a crawl).

We do have members that I know personally routinely have 500-1000 concurrent connected torrent peers, via cryptostorm, so that's the kind of metrics we expect to be able to comfortably carry; indeed, we'd like to carry an essentially unlimited number of peer connections for each member, on average.

Finally, I've seen some consistent reports of torrent clients reporting an inability to NAT thru cryptostorm successfully, in recent weeks. What I don't know is if this is specific to a particular cluster, or network-wide. Folks who are reporting on torrent throughput, that's very useful data to have in terms of helping ops to target what's causing bottlenecks. Also useful are specific settings in torrent clients: UPnP enabled (or not); DHT enabled (or not); max concurrent peers, etc.

My hunch is that there's some undocumented impact on "discoverability" when it comes to the precise SNAT iptables rule-chains we use in exitnodes (most folks simply default to MASQUERADE, but for several security-related concerns, we much prefer specific SNAT POSTROUTING chains to manage session transit). Or, more precisely, I suspect that we're actually NATting sessions (or "sessions," in the case of UDP streams, of course) 100% effectively at exitnodes, but the way in which we're doing it is causing some torrent clients to conclude that we're not - so the result is in some cases suboptimal throughput as the torrent client seeks to optimise performance heuristically, but using assumptions that aren't accurate in terms of how the network is handling NATted traffic. This is all a hunch, at this point, as we've not done proper wireshark analyics on test sessions. Yet.

In general, the way our network is parameterised is to be as "transparent" as possible to userland/app-layer/OSI_7 operations. Ironically, sometimes when we get too good at that, userland can start to get cold feet and assume that something's not working properly... this is in a sense an emergent property of the multi-layered model of topological connectivity implicit in these kinds of decoherent logicalphysical routing setups. That's not a bad thing; rather, it just means we need to keep fiddling with things to get our parameters congruent with the way the actual ecosystem views the world out there.

We do see, from time to time, transient performance bottlenecks in a particular datacentere or other - it happens. It's not supposed to happen, but in the real world nobody has "guaranteed" bandwidth and if the folks running a DC over-sell a given local network segment - or outbound pipe - we'll see throughput for a given machine suddenly crater. This is not unusual, and it's one reason we strive to provision every exitnode cluster with multiple physical machines and, if possible, machines hosted in divergent DCs within a specific geographic region (such as a city). Because clusters dynamically loadbalance intra-cluster, if someone's suddenly seeing poor performance on a given machine and they reconnect, there's a strong probability (this is all stochastic, to avoid race-condition bottlenecks - a lesson learned the hard way, years ago) they'll hit a different machine within the cluster and thus see performance come right back up if it's a DC- or segment-specific bottleneck. As we monitory per-cluster connection metrics, we can actually watch these gradual shifts from slow(er) machines to fast(er) machines within a cluster. Then, if a bottleneck at the DC resolves, we'll see things balance back out over time...

Anyway, the more data points you can throw into this thread (or others) regarding specific session parameters that are resulting in sub-par performance, the more effective Ops can be in nailing down improvements. Vastly more effective, to be honest - the network is big enough now, and diverse enough now, that a report of "poor performance" - even for a specific cluster - is almost impossible to effectively diagnose... it becomes like chasing a ghost. In contrast, something like "UDP sessions on ip xxxx at 7pm UDT Thurs were poor inbound, and outbound" - this allows us to zero right in on a given machine, pull kernel metrics, and immediately see what's up. from ss to htop to powertop and iperf and ethtools and ifconfig and on and on and on... we've got a couple dozen forensic tools to pin down bottlenecks - but trying to find a transient bottleneck across dozens of openvpn instantiations is effectively a low-success task nowadays.

Thanks! :thumbup:


ps: for motivated network members, we can also spin up single-purpose, dedicated instantations for testing of very precise perturbations of session parameters in a controlled setting. This is often extremely useful in moving perf-tuning to new levels, but requires network members willing to do some iterative work in session testing, as well as be somewhat actively engaged in the parameterization process itself. If you're interested in this, email me or Ops (info@cryptostorm.is) and we can get you into the "active tester" team (or whatever we decide to call it ;-) ).
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f[/color]

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by DesuStrike » Fri Feb 07, 2014 3:32 pm

I'd love to do some special testing to improve things (and learn stuff while I'm at it) but I have to pass for now. This kind of work though very interesting is sometimes also time-consuming.
My dedication to forum and community work plus my side-channel CS advisory activity already has a certain impact on my other responsibilities but I love it way too much to just drop it. :angel:
I promise to report in as soon as I can somehow fit it into my schedule.

In the meantime I also encourage everyone dedicated to this project to participate in this opportunity. Especially those who contacted me about topics like package analysis, etc. This is your opportunity to gain some valuable knowledge!


Some basic information concerning my bad performance reports:

General Info:
  • Cluster: Frankfurt (raw-config / unmodified)
  • UPnP: disabled
  • DHT: Enabled (ca. 167 nodes)
  • Connection Status: Mostly green (incomming) but sometimes yellow (no incomming)
  • Incoming Port: random
  • DHT Port: Random (same as incoming port!)
  • PeX (peer exchange): enabled
Connection & Rate Limits:
  • Global maximum number of connections: unlimited
  • Maximum connections per torrent: unlimited
  • Global maximum number of upload slots: 8
  • Maximum number of upload slots per torrent: unlimited
  • Download speed: unlimited
  • Upload speed: 50KByte/s
  • Bandwidth management (uTP): enabled
  • Apply rate limit to uTP connections: enabled
  • Apply rate limit to transport overhead: disabled
  • Maximum number of half open connections: unlimited
home is where the artillery hits

User avatar
Tealc
Posts: 241
Joined: Tue Jan 28, 2014 12:38 am

Re: optimising torrenting performance on cryptostorm: discus

Post by Tealc » Sat Feb 08, 2014 3:00 am

My contribution to the community:

General Info:
Application: uTorrent 3.3.2
Tracker: iptorrents.ru
Cluster: Frankfurt (raw-config / OpenVPN v.5)
UPnP: enable
DHT: disabled
Connection Status: Always green
Incoming Port: 64355
DHT Port: disabled
PeX (peer exchange): disabled

Connection & Rate Limits:
Global maximum number of connections: unlimited
Maximum connections per torrent: unlimited
Global maximum number of upload slots: 20
Maximum number of upload slots per torrent: unlimited
Download speed: unlimited
Upload speed: unlimited
Bandwidth management (uTP): enabled
Apply rate limit to uTP connections: disabled
Apply rate limit to transport overhead: disabled
Maximum number of half open connections: unlimited

Overall:
- Connecting to peers was actually very fast
- More them 10k seeds
- Download speed 1987.6 kB/s
- Upload speed 115 kB/s

I got almost the same download speed that without the CS on. But the upload changes a great deal, I got 900 kB/s.
Just to clear, I really don't use CS to torrent, this was only for the testing.... ehehe

Hope this helps

cryptostorm_ops

Re: optimising torrenting performance on cryptostorm: discus

Post by cryptostorm_ops » Sat Feb 08, 2014 3:00 pm

What happens, for both reported examples so far, when you punch up the cap you've got on maximum upload slots globally?

One thing that's much harder to do through a decoupled/NATted infrastructure is the sort of heuristic best-performing-peer tricks that will allow direct connects to choose (for example) the eight peers who can accept the fastest connections from you. This is doubly so if DHT is disabled, as you're then entirely dependent on the tracker itself to mediate all that stuff... and many trackers are barely able to designate peers let alone do clever optimization of performance.

I'm also curious what sort of A/B results you get if you toggle UPnP on/off in your client. It shouldn't be necessary, and we don't implement UPnP within cryptostorm... but there are some home routers that really want it to be part of their session mediation and it's possible they are enforcing that even in the context of a tunnelled session to cryptostorm.

This morning we've put some test parameters into production in Montreal, to see if we can bump up discoverability (which is really a proxy for UDP session management efficacy) for connected peers... it's not ready for full production, but we're hopeful that it gives a good bump to that particular metric.

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by DesuStrike » Sat Feb 08, 2014 4:31 pm

I switched the upload slots to unlimited but it doesn't really change anything but decrease my download performance a bit.
Unfortunately I have to use the Frankfurt config on my machine here so I can't try out Montreal.

I think I didn't emphasize one fact enough: I can definitely and reproducibly confirm that download speed and upload speed are in direct correlation with one another! If the latter goes up the former goes down noticeably and vice versa. I never saw such behavior before I used CryptoStorm. It's as if the exitnode can only handle a certain amount of connections and packets per second on a global level (up and down) and if you rise one value it has no other option than to crap out on the other one. (That's why I was forced to limit my upload speed and connections.)
home is where the artillery hits

User avatar
Tealc
Posts: 241
Joined: Tue Jan 28, 2014 12:38 am

Re: optimising torrenting performance on cryptostorm: discus

Post by Tealc » Sat Feb 08, 2014 5:05 pm

My 2 contribution to the community:

General Info:
(same torrent file as before)
Application: uTorrent 3.3.2
Tracker: iptorrents.ru
Cluster: Montreal (raw-config / OpenVPN v.5)
UPnP: enable
DHT: disabled (my tracker doesn't allow DHT)
Connection Status: Always green
Incoming Port: 56610 (random)
DHT Port: disabled
PeX (peer exchange): disabled
NAT-PMP: Enable

Connection & Rate Limits:
Global maximum number of connections: unlimited
Maximum connections per torrent: unlimited
Global maximum number of upload slots: 20
Maximum number of upload slots per torrent: unlimited
Download speed: unlimited
Upload speed: unlimited
Bandwidth management (uTP): enabled
Apply rate limit to uTP connections: disabled
Apply rate limit to transport overhead: disabled
Maximum number of half open connections: unlimited

Overall:
- Connecting to peers was very fast
- More them 9905 seeds
- Download speed 1527.6 kB/s
- Upload speed 2.8 kB/s (??????)

User avatar
Tealc
Posts: 241
Joined: Tue Jan 28, 2014 12:38 am

Re: optimising torrenting performance on cryptostorm: discus

Post by Tealc » Sat Feb 08, 2014 5:10 pm

Strangely enough I got better results in the download that in the Frankfurt cluster, the overall speed was very stable, it didn't oscillate like in the other one

cryptostorm_ops

Re: optimising torrenting performance on cryptostorm: discus

Post by cryptostorm_ops » Sat Feb 08, 2014 6:45 pm

Try enabling PeX, btw...
PEXIEEEp2p.pdf
(221.27 KiB) Downloaded 2144 times
Understanding Peer Exchange in BitTorrent Systems
Author(s) Di Wu ; Sun Yat-Sen Univ., Guangzhou, China ; Dhungel, P. ; Xiaojun Hei ; Chao Zhang


Peer Exchange (PEX), in which peers directly exchange with each other lists of active peers in the torrent, has been widely implemented in modern BitTorrent clients for decentralized peer discovery. However, there is little knowledge about the behavior of PEX in operational systems. In this paper, we perform both passive measurements and Planetlab experiments to study the impact and properties of BitTorrent PEX. We first study the impact of PEX on the download efficiency of BitTorrent. We observe that PEX can significantly reduce the download time for some torrents. We then analyze the freshness, redundancy and spread speed of PEX messages. Finally, we also conduct large- scale Planetlab experiments to understand the impact of PEX on the overlay properties of BitTorrent.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Sat Feb 08, 2014 11:37 pm

@DesuStrike

I've no idea what you Internet setup is, but generally with asymmetric xDSL type connections maximising the download speed will affect the upload speed; something to do with allocated spectrum. Going by the speeds you were quoting, can I assume you are on a DOCSIS (cable) connection? Can you normally maximise your download without affecting your maximum upload?

cryptostorm_ops

Re: optimising torrenting performance on cryptostorm: discus

Post by cryptostorm_ops » Mon Feb 10, 2014 3:17 pm

parityboy wrote:I've no idea what you Internet setup is, but generally with asymmetric xDSL type connections maximising the download speed will affect the upload speed; something to do with allocated spectrum. Going by the speeds you were quoting, can I assume you are on a DOCSIS (cable) connection? Can you normally maximise your download without affecting your maximum upload?
This is correct.

Further, it's possible to saturate kernel resources with upload "slots" and thus crimp inbound sessions. These sorts of things are governed by the parameters relating to network/socket allocation... the same sysctl (in Linux) settings we're working with server-side.

As an example of certain upload tools swamping kernel ability to concurrently handle download volume - but not because of ISP or hardware/DSU/CSU issue - try uploading a file to Mega's filesharing site using their default parameters. Doesn't matter if you're on-net (cryptostorm) or not. Spool the upload, let it come up to speed, and then try downloading something entirely unrelated. On most OS flavours, you'll see that the upload effectively monopolises total network stack capacity, and the download gets severely crimped.

This isn't a bug; it's a feature. They've enable concurrent upload streams as a default, via their .js libraries. One can throttle that down (or up) via settings. But even a simple thing like a half a dozen concurrent TLS/TCP sessions being pushed upstream can overwhelm default kernel parameters. I suspect this has to do with the 'tc' algorithms being used (choosing a stochastic socket-allocation procedure would, as a test, eliminate this bottleneck), but haven't actually validated it myself.

For intrepid network members on mainstream Linux distros, it's quite possible to fine-tune kernel settings client-side to maximise performance during cryptostorm sessions; oversimplified, if those settings are congruent by and between clients and cryptostorm exitnodes, session performance is optimised (this is not formally accurate, but is metaphorically useful). At the least, opening up some of the overly-conservative ring-buffering parameters in the Linux kernel (and attendant NIC drivers) can - and does - substantially improve throughput for cryptostorm sessions. We don't actually recommend this in general, as it's beyond the scope of our support folks to help troubleshoot things if problems arise. But, for those with a bit more technical background, a bit of iterative tuning of those parameters can show considerable improvements... bordering on enormous, in some cases. This is all the more true for widely-spanned, multi-swarm, ephemeral UDP session scenarios such as 1000+ concurrent torrent connections.

If folks do play around with those settings, I'm happy to provide unofficial guidance - although I can't promise it'll be top-tier triage level response time. In general, it's "no harm, no foul" to do so - setting them temporarily is easy via "echo" & even saved sysctl.conf edits can be reverted so long as a snapshot is maintained.

We're currently using PJ as a guinea pig for this. He's got a Linux box in the office that's now running an identical (1.6) sysctl.conf as runs on nearly all of our production exitnodes... on an old laptop. Somewhat surprisingly, it works fairly well - although occasionally the "minimum allocation" memory settings lock up his machine tight, as they're calculated for dedicated servers with dozens of gigs of fast-poll, low-error RAM... and old laptops don't quite fit that profile.

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by DesuStrike » Mon Feb 10, 2014 4:34 pm

Well everything parityboy assumes is correct and everything our furry little friend (or should I say "little furry friend" ;) ) says is most certainly true.

What still bugs me is that I'm fairly sure to remember having full download speed in the past when I throttled upload to 50 KB/s while being on CS. But my memory might be playing tricks on me.
I also know for a fact that I have full down-speed when I'm not on CS. In either case my router is pretty bored with what I trow at it. Neither CPU or RAM show any signs of being strained to much and I'm not even close to the maximum connection limit.
So I guess this has something to do with Ubuntu handling tons of encrypted connections in both directions at the same time due to being on CS. I won't play with my sysctl around too much now but maybe it's something to do in the future.


As I have almost full download speed when not doing p2p I'll try out this simultaneous up/down experiment cs_ops suggested. I wonder how that will play out!
home is where the artillery hits

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Mon Feb 10, 2014 5:06 pm

@cryptostorm_ops
At the least, opening up some of the overly-conservative ring-buffering parameters in the Linux kernel (and attendant NIC drivers) can - and does - substantially improve throughput for cryptostorm sessions. We don't actually recommend this in general, as it's beyond the scope of our support folks to help troubleshoot things if problems arise.
In your experience, how well does this work from a virtualisation perspective? Many of us (including myself) run our torrent client in a Linux guest, typically VirtualBox. Will host kernel parameters need to be optimised, as well as the guest ones? How well do the built in VBox NIC drivers (AMD, Intel) respond to such optimisations, if at all? Do any of these optimisations affect the tun0 driver, or just the underlying physical (or virtualised) NIC driver?

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Mon Feb 10, 2014 11:12 pm

@DesuStrike

Considering the fact that your router is effectively handling a single connection (i.e. the VPN tunnel), it's no surprise it's not breaking a sweat. If your router was handling the VPN client endpoint, things might be a little different...

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Tue Feb 11, 2014 1:01 pm

In uTorrent, go to Options - Preferences - Advanced...
In the Filter text box, type "isp." and there should be 7 entries to tinker with...

The Primary and Secondary DNS entries, according to IP Lookup, are located in the USA.

The following is provided by netchief.com
isp.bep22: This option enables Local Tracker Discovery accordonmg to BEP22 (BitTorrent Local Tracker Discovery Protocol), allowing µTorrent to attempt to discover ISP-local trackers via a series of reverse DNS lookups. The ISP-local tracker can return a list of peers and caches (most likely ISP-local). Note that if your ISP is known to interfere with BitTorrent traffic, careful consideration should be taken in deciding to enable this option. Announcing to a ISP-hosted tracker indicates to the ISP that you are using BitTorrent, and as such, can make it easier for the ISP to interfere. Private torrent jobs are not announced to local trackers.
isp.fqdn: If your ISP does not return a correct reverse-DNS name, this allows you to set your reverse lookup name for the purposes of BEP22
isp.peer_policy_enable: This option enables peer policy functionality, which sets weights to different IP ranges.
isp.peer_policy_override: This option overrides the peer policy.
isp.peer_policy_url: This option sets a URL to the ISP's peer policy.
isp.primary_dns: This option sets the primary DNS server Ip of your ISP.
isp.secondary_dns: This option sets the primary DNS server Ip of your ISP.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Wed Feb 12, 2014 12:27 am

@DesuStrike

I've just completed some basic testing using KTorrent 4.2 on Mint 15 KDE, running on a bridged VirtualBox instance. In KTorrent you can choose to use:

a) TCP for peer connections, exclusively
b) uTP for peer connections, exclusively
c) prefer one, then fall back to the other

Having 5 torrents seeding and none dowloading, I can continuously push maximum upload (96KiB/s) when using (or preferring) TCP connections. When uTP is used (or preferred), the upload speed swings from 13KiB/s to 40KiB/s to 60KiB/s, up to about 85KiB/s and then back down again. Highly variable.

If you are using uTorrent, can you force it to use TCP connections and then see how it performs? It may well be the nature of the uTP protocol that it will behave this way, or perhaps it's a property of UDP. All of my testing was done while connected to CS - so we can rule out any BitTorrent-specific QoS by my ISP - but it could be that the data streams are affected once they exit the CS network.

I tried doing the same with a Linux Mint torrent on the clear side, on the host using KTorrent 4.1.3. I used uTP exclusively; downloads went at maximum line speed, but due to the sheer number of (much faster) seeds, I wasn't able to gain any useful behavioural data regarding uploads.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Wed Feb 12, 2014 7:01 am

Something I mentioned in the "port forwarding" thread that I'd like cleared up. On the old network, I was allocated a specific port; I set my torrent client to use that port and I was able to receive inbound connections (tested with telnet).

On the new CS network, I'm specifying the very same port in the torrent client (KTorrent), but if I telnet to that port on the exit node's IP address (from outside the VPN), I get "connection refused". I made sure my local firewall is not blocking inbound connections to the specified port, and I can telnet to the port on the loopback address and the local LAN address (I set the client to listen on all addresses, for testing purposes).

Additionally, from within the CS network I can telnet to my host computer which is running its own torrent client, on the host torrent client's published port (portforwarded through the router, obviously) and get an open connection.

To my mind, this means my VM'd torrent client (connected to the CS VPN) cannot receive inbound connections initiated from other peers, and therefore when seeding will have to wait until a peer that can accept inbound connections joins the swarm before being able to seed data. Obviously, this will reduce the efficiency of the swarm, since it might be a while before a connectable peer joins the swarm. In fact, I noticed this behaviour tonight when seeding a new torrent.

How can I improve this, or is there nothing I can do?

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Fri Feb 14, 2014 6:58 am

@DesuStrike

Just out of interest, do you know if your torrent client is "connectable"? Can peers initiate a connection to you?

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Mon Feb 17, 2014 3:54 am

@DesuStrike

Just saw this post of yours, and I believe you are correct: with no way to find your torrent client (hidden deep within the CS network), peers outside will not be able to initiate connections to your client. This means that two peers connected via CS, using a private tracker sited outside of the CS network and not using DHT, will not be able to seed data to each other, as far as I can see.

User avatar
Pattern_Juggled
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: optimising torrenting performance on cryptostorm: discus

Post by Pattern_Juggled » Tue Feb 18, 2014 6:03 pm

parityboy wrote:Just saw this post of yours, and I believe you are correct: with no way to find your torrent client (hidden deep within the CS network), peers outside will not be able to initiate connections to your client. This means that two peers connected via CS, using a private tracker sited outside of the CS network and not using DHT, will not be able to seed data to each other, as far as I can see.
No, no... you've fallen into a fallacy of recursion.

Trackers exist to track peers in a swarm, centrally. DHT does this in a decentralised way, by doing a form of local-broadcast availability somewhat analogous to ARP data propagating locally.

Now obviously a tracker can facilitate swarm-based sessions on-net and off-net (i.e. cryptostorm) - that's what trackers do, and it's no more complex than a webserver pushing traffic over to an on-net client. DHT is more clever; it does an iterative search process, to build out the topological relationship of peers in a swarm. It's quite elegant - but given its author, no surprise. It's bidirectional, too - so as soon as a client in a DHT'd swarm starts talking to other clients, that topological reticulum starts to build out. The fact that one peer is NATting through cryptostorm is irrelevant, of course - that's the whole idea of (real) NAT.

Sit on wireshark and watch a DHT'd swarm form and evolve, over time. It's fascinating.

This is all ephemeral, right? DHT swarms have no central "lookup table" as to who is where, assigned what IP, etc. That's what trackers do - DHT doesn't. It builds the reticulum dynamically, and doesn't try to hold onto it. So a peer sitting inside cryptostorm is no different from any other peer.

As to what's really going on, it's the SNAT directive encoded in the Linux kernel. I was once studying all the clever things those four little iptables initials do, and came across a statement to the effect that "SNATting TCP sessions is straightforward, and almost trivial - maintain a lookup table, temporally; however, proper SNATting of UDP streams requires creativity bordering on black magic." Indeed. Because UDP doesn't have "sessions," everything in the chain of UDP connectivity has to make heuristic assumptions about packet streams. Mostly it works - amazingly so. Sometime it hiccups.

UDP going through cryptostorm - and here we're of course talking about UDP over UDP, not the data channel UDP encapsulation itself - is no more prone to black arts issues than is UDP transiting a bunch of hops on the internet itself. Our exitnodes have to be smart enough to recognise UDP packets and know which internal subnetted "client" gets the packets. Usually the kernel does that amazingly well. Sometimes UDP packets are "orphaned" - they got there too late, or malformed, or whatever, and the NIC generally tosses them. There's tools (ss) to track those metrics on the physical NICs and make sure there's not issues. We do that tracking. Also, those sysctl settings have a big impact on UDP transience, in my own experience. But I'll say that if we see even a percent or two of "lost" UDP packets at the NIC, that's a big red flag. In some cases, we really do see zero for days at a time.

Finally, because so many ISP fuck with torrent swarms - either admittedly, or surreptitiously - it's very, very common to have better discoverability on-net with cryptostorm, than off. That's not exceptional - it's common. It might take some fiddling with the torrent client to be sure it's happy with the NATting and isn't tying to out-NAT the exitnodes, for example - but that's about it. A bit of trial and error is in order, as so many of these protocols are intrinsically heuristic - there's going to be emergent behaviours aplenty when you stack them on each other.

If you're ever bored, it's also possible to sit on a physical NIC and watch UDP/socket bindings as they evolve over time, one after another... there's a rhythm to it, hard to describe. That's the guts of torrent connectivity, right there. Sufficient socket resources are part of the puzzle of ensuring all those UDP streams come and go more or less as intended. More or less because, hey... it's UDP! :-P
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f[/color]

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Tue Feb 18, 2014 7:07 pm

@PJ

Thank you for your reply. However, I need to make a point or two, and from there I'd like you to explain what I'm seeing.

Let's say I'm connected to private non-DHT tracker pt via cryptostorm. My client periodically scrapes pt, informing it of the torrent(s) it has, its IP address and the port it can be found on for inbound connections ("connectability"). In my real world case, the port I use is 34955. Also, KTorrent primarily uses TCP for peer connections, although it can use uTP also.

Since I'm the only seed for this content, any client wanting this content will attempt to initiate an inbound connection to my client. In other words, my client will be acting like a server. On the clear net, this is easy: I portforward on my router, and the inbound connection is made.

This is similar to the set up I had on the old Cryptocloud network: I was allocated a port, so all I had to do was ensure my client was up and running and on the same port. On CS however, if I telnet to port 34955 on the exit node, I get "Connection refused". I assume netcat will behave the same way.

So, I can only assume that if I post content to a torrent site and I'm the only seed, a client attempting to initiate a new inbound connection to me will fail, which to me makes sense: how would your exit node know where to route the packets for a new inbound connection? I've noticed this in terms of being aware of a number of leeches demanding content from my client (according to the tracker), but no connection being made. As soon as they connected to the tracker they would have been aware of my client as the only seed.

However, I have also been made aware that a BitTorrent seed can effectively "push" data to a leech, as long as that leech has an accessible port for accepting inbound connections, i.e. the leech is "connectable". As far as I can see and have read, if a both a seed and a leech cannot accept new inbound connections, they cannot exchange data and will have to wait until a "connectable" peer comes along to help facilitate data propagation.

So the obvious question is this. If I cannot make an inbound connection to my CS-connected client from the clear 'Net via the exit node IP, how can anyone else? In fact try it yourself: I'm on the Frankfurt exit node. Try connecting to port 34955 (TCP) and share the result, I'm keen to see if you can make a connection. It's also a learning opportunity for me: my networking knowledge is limited to the basic stuff. :)
Last edited by parityboy on Tue Feb 18, 2014 7:46 pm, edited 1 time in total.

User avatar
Pattern_Juggled
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: optimising torrenting performance on cryptostorm: discus

Post by Pattern_Juggled » Tue Feb 18, 2014 7:43 pm

parityboy wrote:This is similar to the set up I had on the old Cryptocloud network: I was allocated a port, so all I had to do was ensure my client was up and running and on the same port. On CS however, if I telnet to port 34955 on the exit node, I get "Connection refused". I assume netcat will behave the same way.
Quick reply for now: what's happening is that you're trying to telnet directly into the exitnode itself... and that machine of course rejects that connection as it will reject most everything trying to bind to its resources (all the usual IDS/iptables gadgets running on exitnodes). You can see how there's absolutely no way that a telnet to that physical IP will do anything except... attempt to make a connection to that actual machine.

But torrent swarm "connections" are really nothing like telnet - telnet is a tight protocol that's accessing machine resources in a privileged manner. A torrent connection is a loosely advertised "hey I've got some stuff - here's the hash - do you need it? Oh, and what do you have..?" We call both "connections," but they are nothing like each other.
So the obvious question is this. If I cannot make an inbound connection to my CS-connected client via the exit node IP, how can anyone else? In fact try it yourself: I'm on the Frankfurt exit node. Try connecting to port 34955 (TCP) and share the result, I'm keen to see if you can make a connection. It's also a learning opportunity for me: my networking knowledge is limited to the basic stuff. :)
The way trackers actually work, if you ever admin one from the backend is as follows: they wait for swarm participants to contact them when available and then they keep that connection profile stored locally in a database - generally for a number of minutes (60 is common, 20 is not rare) driven by how much power the machine has and how big the swarms are it's supposed to be tracking. If it doesn't hear from that client within that timeframe, it'll flush it from its available peer tables until it hears from that client again. And of course the client always knows how to find the tracker, as the tracker has a fixed canonical domain name that has attendant A Records pointing to a specific publicly-routable IP.

The client, in contrast, needs none of that. It can be dhcp'd, dyn-dns'd... whatever. It is the one that opens the channel to the tracker, for every session (the tracker knows who it is either based on simple login creds passed via SOAP or whatever, or via an embedded identifier within private torrents themselves - you can see it in the torrent details, if you look, for 'private' tracker torrents). So there's no sense of the tracker actively reaching out to peers and trying to "keep them connected" - not in any tracker backend I've ever seen or run myself, in any case.

So obviously, when the peer reaches out through cryptostorm to the tracker to say hullo, the SNAT rulesets living in the kernel of the exitnode being used get that crucial first-run socket/port/protocol pairing as the session (or stream) initiates. Aha! So now we know, if packets come back with those characteristics in a bounded timeframe, we'll go ahead and NAT 'em down to the following ephemeral subnet address: 10.55.0.23 (or whatever in the 10.55.0.0/16 if it's a raw connection instance). A bit of magic there, but nothing amazing - since the handshake opens up all the bindings and thus clues NAT in to the future status of that session (or "session," if it's UDP).

If you want, in contrast, to make telnet services available on your local machine to the larger network beyond cryptostorm - and you want to do so persistently over time - then you'd have to use different tools to ensure discoverability... just as are needed in any dhcp'd, non-routable local subnet topology - which means most residential ISP connections in most areas of the world. Very few folks really want to do this, for obvious security reasons: running one's local machine as a full-on server is a big step. To be clear, we're fine with it at cryptostorm - have fun! But it's not common to see.

There are several folks, I suspect, running full-blown seedboxes from within cryptostorm and thus using the darknet to wrap their physical transit pathways in a layer of obfuscation. That's not some forensic work to make this conclusion, but rather having enough experience with meta-network stats to notice certain regular patterns coming through (highly asymmetric outbound traffic on a given node, for example). We're 100% fine with it, if in fact that's happening - I'm quite curious to know what sort of networking setup is being used to do it, and someday I hope to learn. But that's up to the member, whom we suspect is being coy for fear of being "cut off" if we find out what she's doing. We'll do nothing of the sort, to be clear - but folks do assume that, unfortunately.

An interesting discussion thus far - thanks for participating.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f[/color]

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Wed Feb 19, 2014 4:05 am

An interesting discussion indeed. :) So basically, it's up to clients buried within cryptostorm to initiate connections to the wider Internet, in order to receive data. "Cold calling" them at the exit node's IP address will not work, so for BitTorrent seeds which publish the exit node's IP address, they have a dependency upon another peer not only being discoverable via a tracker, but also being contactable i.e. able to accept connections initiated from elsewhere.

This is why I made the point about the two peers (seed/leech) sitting inside the CS network trying to exchange data directly with each other. If the tracker tells the leech "the data you want is at 46.165.222.246:34955. Good luck." and that leech tries to initiate a connection to that address and port, then as you say quite rightly it will fail. Miserably. If the seed tries to push data to the leech that will fail too since the leech is at the same external address, albeit on a different port (hopefully).

However, if a second leech appears (and isn't hiding behind something), and is contactable on an open port, the seed can then initiate a connection to that second leech and push data to it. The first leech (following an update from the tracker) can then contact that second leech and pull data from it. Unfortunately, it means the peers have to wait for a connectable peer to show up.

This brings me to my second point. Can network peers within the CS network find each other without their traffic exiting CS? Can the network route traffic that way? Would it be possible to have a tracker and peers communicating completely within CS?
There are several folks, I suspect, running full-blown seedboxes from within cryptostorm and thus using the darknet to wrap their physical transit pathways in a layer of obfuscation. That's not some forensic work to make this conclusion, but rather having enough experience with meta-network stats to notice certain regular patterns coming through (highly asymmetric outbound traffic on a given node, for example). We're 100% fine with it, if in fact that's happening - I'm quite curious to know what sort of networking setup is being used to do it, and someday I hope to learn. But that's up to the member, whom we suspect is being coy for fear of being "cut off" if we find out what she's doing. We'll do nothing of the sort, to be clear - but folks do assume that, unfortunately.
At a guess, and based on my limited networking knowledge, I'd say that their seedbox (if that's what it is) is possibly being fronted by what you might call a "socket server" sitting on a VPS (probably) out on the wider Internet. Their seedbox likely initiates a connection to the socket server, and possibly uses port translation (iptables) so that any data coming back from the socket server is directed to the bittorrent port of the seedbox. I'd guess that TCP would probably be easier to work with for something like this, compared to UDP.

If their seedbox uses rtorrent (most do) it probably wouldn't be that difficult to modify the source code to make that inital outbound connection on startup. Having said that, it could also be that they have written a socket server that's local to the seedbox and that basically performs as a mirror to the one on the VPS, except that it initiates connections to the VPS and the local rtorrent. There are plenty of very basic open source server frameworks that could be used for this.

The socket server on the VPS would also have to accept connections from the wider Internet (obviously) and basically join the initiated connections from the Internet to the reply channel from the socket server back to the socket server on the seedbox. It's possibly a clever combination of iptables and "cross wiring" of I/O streams.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Sun Feb 23, 2014 3:59 am

@PJ

Actually, I've over-complicated it. They can use reverse tunnelling with SSH. Use the "front server" mentioned earlier and create a reverse tunnel from the seedbox to the "front server" using SSH. This will allow the hidden seedbox to have a stable port accessible from the wider Internet. I've no idea how scaleable it is in terms of traffic, but based on some simple experiments I'd say it's a viable solution. However, to be effective it would require an anonymously purchased, disposable VPS with a high bandwidth allowance.

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by DesuStrike » Fri Feb 28, 2014 6:04 am

UPDATE!

I cannot pin down the exat day since when things started to change but I think it is not more than 5 days ago.

I absolutely changed nothing but all of a sudden torrents work like a charm for me. Not only torrents: Steam for Linux always was a major pain in the ass because it only downloaded in bursts. 1Megabyte per second FOR one second and then gradually dropping down to almost nothing only to spike up for another second after crawling around for a minute or two. Now Steam sucks down bytes stronger than a... oh well... ok I'm getting overexcited. So it's basically 5 Megabytes per second now.

So whatever you guys did to the exitnodes: Please keep it that way! It's awesome! :thumbup:
home is where the artillery hits

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Fri Feb 28, 2014 6:40 am

I get better down/up stream results now that I default to the USA exitnode... can max out bandwidth on public trackers. Private needs not to be mentioned, always fast on those ones. Max downstream I've seen on the darknet is 1.1MB p/s, not sure why it stops there since without darknet I get 1.7MB p/s. I guess that might be due to being on ADSL2+, distance from exchange, plus router provided by ISP.

I haven't forwarded ports. I have disabled the following: UPnP port mapping, NAT-PMP port mapping, DHT, Local Peer Discovery, Peer Exchange, Bandwidth Management and UDP.
bt.tcp_rate_control set to false...
IPv6 is disabled on OS and therefore, on uTorrent...
I also change net.bind_ip and net.outgoing_ip to the IP assigned by the darknet whenever I log on...

User avatar
spotshot
Posts: 98
Joined: Sun Feb 10, 2013 11:23 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by spotshot » Fri Feb 28, 2014 8:34 am

I tried changing net.bind_ip and net.outgoing_ip to the IP, but it still grabbed by normal ip if CS goes down,
Im still using VPNetMon to kill utorrent if CS goes down.

I used same setting, except for DHT, Local Peer Discovery, Peer Exchange
the more seeders the better,

I have found from time to time I get red icon on sharing, but if I grab another port
and restart utorrent it jumps back to green.

both UPnP port mapping, NAT-PMP port mapping seems to kill any chance of quick downloads,
old set up needed them, but new CS doesn't.

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Fri Feb 28, 2014 11:11 am

spotshot wrote:I tried changing net.bind_ip and net.outgoing_ip to the IP, but it still grabbed by normal ip if CS goes down.
I tried to replicate this, but couldn't. I logged off the darknet, and torrents stopped downloading/uploading. Wierd.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Fri Feb 28, 2014 3:43 pm

marzametal wrote:I get better down/up stream results now that I default to the USA exitnode... can max out bandwidth on public trackers. Private needs not to be mentioned, always fast on those ones. Max downstream I've seen on the darknet is 1.1MB p/s, not sure why it stops there since without darknet I get 1.7MB p/s. I guess that might be due to being on ADSL2+, distance from exchange, plus router provided by ISP.
It could be your ISP de-prioritising VPN traffic, it could be that your CPU isn't fast enough (doubt it), could be a routing or latency issue. Try doing a large HTTP download over the darknet, like a Linux DVD or something and report back what you get.

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Sat Mar 01, 2014 5:09 am

Blah, couldn't break 200KB p/s...

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Sat Mar 01, 2014 6:09 am

@marzametal

That sounds like traffic management. Try this link. Run a few tests and see which link is fastest for you via HTTP and/or BitTorrent. However, assuming you actually are in Australia, your data will go through a fair few hops from the USA exit node back to you.

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Sat Mar 01, 2014 9:43 am

@parityboy

Oddly enough, that is the download I ended up choosing to test... lol

User avatar
acid1c
Posts: 42
Joined: Sat Aug 31, 2013 5:42 am

Re: optimising torrenting performance on cryptostorm: discus

Post by acid1c » Sat Mar 01, 2014 9:09 pm

Lately im running at 400-500Kbps throughVuze with 2 seperate peer identities and transport encryption required. But tribler I seem to get faster connections lately. Im currently at !Mbps with Tribler. Cant wait for tribler 6.3 for built in tor in which they promise pretty amazing speeds. :)

Id like to note, make sure ur allowing ports 80, 6969, and 1337 for the trackers. especially 1337 as tpb adds it to all of their torrents now.
Bitmessage me with Questions, Help, or ChitChat :) - BM-2cV5BzWc9P7vufQREE8Be4U64GBgRJ3GnT
" Those who do not move, do not notice their chains." -Rosa Luxemburg

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Sun Mar 02, 2014 3:02 am

@acid1c

Forgot about Tribler! Gonna have to revisit that at some point. :) By the way, what's your Internet connection? Also, isn't TPB trackerless now, although even on Magnet links I'm seeing connections to trackers...

User avatar
spotshot
Posts: 98
Joined: Sun Feb 10, 2013 11:23 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by spotshot » Tue Mar 04, 2014 9:48 am

Ive lost yellow or green icon in utorrent, only red for last few hours, is anyone else getting same thing,
tried both montreal and USA ?

revised - got green on Iceland node, still red on USA an Montreal

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by DesuStrike » Sat Mar 08, 2014 10:30 pm

I might solved the mystery why we can't get proper inbound connections and absolutely no working DHT when using CryptoStorm.

I connect to CryptoStorm via network-manager.
This screenshot shows logs from my router.
Please note that in this screenshot DHT and listening port are the same. When I put DHT on it's own port you get basically the same result but with an addition log entry for its designated port.

My interpretation of this chart is that P2P clients try to enable inbound traffic by establishing an additional connection to the CryptoStorm servers with the client selected inbound port. This obviously fails because we can only connect via Port 443 to exit nodes.

This brings up 2 questions to my mind:
1. How can we fix this?
2. Does that mean P2P clients partially bypass the VPN tunnel and send unencrypted traffic towards the CryptoStorm servers where it gets eventually dropped?
Selection_053.png
home is where the artillery hits

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Sun Mar 09, 2014 12:53 am

@DesuStrike

You can't fix it. The exits will very obviously permit reply packets, but initiating a connection from outside of the darknet will fail because there's no mechanism to permit it.

To allow inbound connections to be initiated from outside of the darknet, flow along the VPN connection and terminate at your BitTorrent client, the CS team would have to enable inbound ports like on the old CC network. Once the number of users on a given cluster hits a certain point, you will either a) get collisions where more than one user is using (for example) port 35236, or b) simply run out of ports due to the sheer number of users active within a given timeframe.

Additionally, even if the ports were dynamically assigned, they would stay allocated as long as the VPN session stays active, so they would effectively be reserved. Falling from this, a user would most likely get a different port every time they connected, and so would have to manually configure their torrent client accordingly. If the ports were dynamically rotated during a session, that would be even worse. Basically, at this scale port forwarding to support inbound connections becomes very unmanageable, very quickly.

The only way around it is to initiate a reverse tunnel from inside the darknet to what I call a "facade server" (tunnel server) like a cheap VPS, using something like SSH. The connection is initiated from your machine and terminates outside of the darknet. Make sure that you client is listening on localhost, and make sure that the other end of the pipe will forward connections from the wider Internet back along the tunnel to your BitTorrent client. You also have to make sure that the BitTorrent client forcibly gives the tracker the IP address of the VPS, and that the SSH server on the VPS permits gateway ports.

Code: Select all

ssh -R vps.inter.net:12345:localhost:54321 user.name@vps.inter.net
I have actually tested this, and yes it does work. I didn't actually seed with it (VPS provider will not permit it), but I can see my BitTorrent client logs accepting a connection when I have telnetted to the socket on the VPS from the wider Internet. You could probably do the same with GRE tunnels, but those are unencrypted.

As much as the model CS has chosen is a pain in the proverbial for initial seeding (you are basically dependent on 1 or more BitTorrent clients joining the swarm which actually have an open and accesible port, so that you can push data to them), I think it is the right model and by using disposable tunnel servers you can make darknet services much more secure. :)

To answer your second question, if your routing tables are set correctly your client will not be able to bypass the VPN tunnel when it is active. A firewall will make sure it can't send stuff in the clear when the tunnel is not active.

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by DesuStrike » Sun Mar 09, 2014 9:27 am

Very interesting reply!

Does this look good to you? I'm a bit confused about the two lower entries of these four. :eh:
Selection_054.png
home is where the artillery hits

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Sun Mar 09, 2014 5:22 pm

@DesuStrike

Yep that's what I have also. Btw, "network addr.0" is likely 192.168.1.0, and "local router ip" is likely 192.168.1.1 (or 192.168.1.254) which is what nearly everyone runs on their internal LAN, including me. You won't give anything away by showing that; it's non-routable on the public Internet. :)

User avatar
DesuStrike
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: optimising torrenting performance on cryptostorm: discus

Post by DesuStrike » Sun Mar 09, 2014 8:39 pm

Thanks! Always good to compare your config outputs with others to find possible blunders.

So you actually tell me if somebody manages to get access to my local lan, they won't be stopped by my awesome secret DHCP managed local IP arrangement? ;P

You are right of course but it's a habit of me to blend out personal information as much as possible, no matter how trivial it might seem to be. I honestly don't see any possibility how this 100% generic IP config could become problematic information but there are other things that seem to be similarly low in their thread potential but end up becoming problematic one day. So I keep that habit. :)

I actually HAVE to tell this anecdote: A couple years ago I found some very old chat logs between a friend of mine and me. Dunno why and how they ended up on my backup. Anyways: A quick look into them turned out it was tons of lengthy discussions about all kinds of topics. So we met in teamspeak and I read out loud from those logs. We died a thousand deaths with every line I read out. At some point we were both ready to pick up a gun, point it at our head and pull the trigger if one was ready to grab in front of us. Your past self can be someone you don't want to be reminded of, let alone be associated with. We both agreed on me shredding those log file for good.
So yes... You never want to have old information lying around in public. NEVER!
home is where the artillery hits

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Sun Mar 09, 2014 9:47 pm

@DesuStrike

hahaha, well you have a point. There are textual posts on Usenet that date back to the 1990s - that's right, 20 years and counting.

"If it goes on the 'net, it stays on the 'net".

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Mon Mar 10, 2014 5:25 am

parityboy wrote:@marzametal

That sounds like traffic management. Try this link. Run a few tests and see which link is fastest for you via HTTP and/or BitTorrent. However, assuming you actually are in Australia, your data will go through a fair few hops from the USA exit node back to you.
I figured out what makes the speed drop. (puts on dunce hat again)... All is fine until I swap the ISP DNS entries in my router with CS DNS entries. When I connect to the darknet without modifying the DNS entries, I see a DNS leak when I test on various sites. After the swap-over, the leak is gone but the bandwidth is wounded.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Mon Mar 10, 2014 6:08 am

@marzametal

Try putting the original DNS entries back into your router, on your PC in the Control Panel network settings set your network to either manual or DHCP (addresses only), and then manually specify the CS DNS servers in the appropriate section. Doing this, your router won't be involved in forwarding and answering DNS requests.

It might help, might not. :)

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Mon Mar 10, 2014 6:50 am

@parityboy

Cheers for the advice fella... seems to have done the trick! Wrapped like a Christmas present I am...

njaard
Posts: 4
Joined: Wed Jul 09, 2014 5:05 am

Re: optimising torrenting performance on cryptostorm: discus

Post by njaard » Mon Jul 14, 2014 7:21 am

I think Cryptostorm really should permit incoming ports for torrent traffic. Torrents that have few seeders may not allow me to download at all because they see that I'm not seeding. And these are the same torrents that need new seeders the most.

Maybe cryptostorm may not want to support UPnP, but even a custom app just to request a port would be handy, because then I could script the torrent client to ask for a port when I startup and connect.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Mon Jul 14, 2014 6:38 pm

@njaard
Torrents that have few seeders may not allow me to download at all because they see that I'm not seeding. And these are the same torrents that need new seeders the most.
Are you talking about private trackers, open trackers or using magnet links? I don't think people on open trackers will care (most of them are hit 'n' run) and on a private tracker the main issue with regard to CS' model is when you are the only seed and no one else can connect to you (and you can't connect to them either).

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Tue Jul 15, 2014 6:58 am

Also, some private trackers don't allow unrecognised hosts by default. A couple of trackers I have used refuse to allow me to connect while on darknet.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Tue Jul 15, 2014 5:03 pm

@marzametal

You mean the host they see doesn't have a valid DNS entry? I'm sure Cryptostorm's nodes do. Does that apply to every CS node you connect to?

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Wed Jul 16, 2014 5:33 am

@parityboy

So far I have tried Cantus, Emerald and Shadow. I "think" Onyx as well. I will bring up the error message again and include it in this post as an edit... hold on champ.

EDIT: Blah, it works now... damn intermittent errors! So annoying...

njaard
Posts: 4
Joined: Wed Jul 09, 2014 5:05 am

Re: optimising torrenting performance on cryptostorm: discus

Post by njaard » Thu Jul 17, 2014 10:08 pm

@parityboy

Open trackers in particular. But hosts there do care because if the single seeder is a supernode, I may never never actually get the file.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Fri Jul 18, 2014 12:22 am

@njaard

I think you're talking about a couple different things.

1. If the node you're trying to connect to is Superseeding, then yes that can be an issue due to the way superseeding works, and isn't related to CryptoStorm at all.

2. If those peers do a connectivity test upon you (which will fail), then yes perhaps they will not permit you to leech from them.

3. Some peers may reject you if they cannot do a reverse DNS lookup. I've not been a victim of this though, at least as far as I am aware.

njaard
Posts: 4
Joined: Wed Jul 09, 2014 5:05 am

Re: optimising torrenting performance on cryptostorm: discus

Post by njaard » Fri Jul 18, 2014 7:59 am

@parityboy

The result of all of these results in degraded or no performance in torrenting. The first two are definitely related to CryptoStorm because a design feature of IP is that all hosts can be servers. NAT was a workaround for the shortage of IPv4 addresses (and for that it's relatively inconvenient to route); UPnP and port forwarding (on home routers) was a workaround for how NAT loses you the "all hosts can be servers" feature. Before NAT was popular, lots of services required this feature, like ICQ (remember that?).

Here are the problems bittorrent has with CryptoStorm's lack of incoming ports (which I take as a synonym to "VPN" below):
1) in a network with lots of VPNs, bittorrent is no longer P2P because only nodes with incoming ports can interact with the VPN nodes, so your total throughput becomes proportional to the number of full nodes that are not superseeders, as opposed to how bittorrent is supposed to be, which should be proportional to the total amount of upload bandwidth across all users
2) a torrent which loses all of its peers except for the VPNed ones will no longer be accessable to VPN users, which *is* a problem for unpopular torrents - they could literally have one new peer in a month
3) a VPN user who tries to download off a very active torrent will still have degraded performance because only peers with incoming ports who are not superseeders will transmit to you

So, basically CryptoStorm's lack of incoming ports makes VPNs less effective, not just for CryptoStorm users but for *all* VPNs that lack incoming ports. And moreso, CryptoStorm's lack of incoming ports makes BitTorrent less effective for *all* BitTorrent users by making VPN users mostly leechers.

My conclusion is that without incoming ports, CryptoStorm is basically useless for Torrent users, and damages the utility of bittorrent and VPNs as whole.

If CS's reluctance to support this feature is in the name of security of your users, then I ask that CS not make that decision on behalf of its users - afterall, I could go to nsa.gov over the VPN and give them my name and mailing address if I so desired. If CS's reluctance is due to a lack of capacity, then you should not sell us unlimited bandwidth a fixed price, or at least say so.

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Fri Jul 18, 2014 10:23 am

This is just a forum thread on torrenting over CS. CS has never said their primary mission statement is to light a fire under or to breathe new life into the torrenting industry. It's the end users who bark that torrenting should be a right, not a privilege etc... The CS home page does not mention anything about torrents either. In Post #3, PJ goes on about torrents, but that's about it.

"My conclusion is that without incoming ports, CryptoStorm is basically useless for Torrent users, and damages the utility of bittorrent and VPNs as whole."
"So, basically CryptoStorm's lack of incoming ports makes VPNs less effective"
Don't fuckin' ruin it for the users who just want serious network security: opensource, anonymous token auth, drama-free. If you want incoming ports so badly, go jump on the VPN honeypot bandwagon. That way, you won't need to go to nsa.gov and give them your details. The VPN maggots will do it on your behalf. You want to hide from the spies, but break the law at the same time...

User avatar
cryptostorm_support
ForumHelper
Posts: 133
Joined: Sat Jan 26, 2013 4:31 am
Contact:

Re: optimising torrenting performance on cryptostorm: discus

Post by cryptostorm_support » Fri Jul 18, 2014 11:36 am

Thank you, marzametal. The VPN market is getting ever more crowded and if you want to sacrifice security for torrent performance, I have no doubt that there are plenty of people who would gladly take your money and sell you out at the first inkling of pressure.

CS' mission is to provide a broad VPN service with security as our ultimate concern. Those are our terms. Of our list of priorities, you might find torrent functionality on there somewhere, but I can assure you it's not near the top and it'll get shoved to the bottom if we feel it may compromise the security we've worked hard toward, and that our customers expect.
cryptostorm_support shared support team forum account
PLEASE DON'T SEND PRIVATE MESSAGES with support questions!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Fri Jul 18, 2014 3:07 pm

@njaard
1. If the node you're trying to connect to is Superseeding, then yes that can be an issue due to the way superseeding works, and isn't related to CryptoStorm at all.
If the node you're connected to is superseeding and you are the only peer, you will suffer regardless of whether you have incoming ports or not. Taken from the link:
Super seeding transfers stall when there is only one downloading client. The seeders will not send more data until a second client receives the data.
As for the rest of your points, you are correct. For full BitTorrent functionality, incoming ports are a must-have and Cryptostorm does not support them - they are actually incapable of fitting within the Cryptostorm security model. The CS team has already donetheir best to route torrent traffic correctly to avoid port forwarding, but the security model has meant that peer connectability suffers somewhat. For me personally, it's a sacrifice I can live with. :)

User avatar
marzametal
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: optimising torrenting performance on cryptostorm: discus

Post by marzametal » Sat Jul 19, 2014 6:16 am

Wouldn't providing incoming ports expose the darknet? I don't want to wear a t-shirt saying convenience > security.

User avatar
parityboy
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: optimising torrenting performance on cryptostorm: discus

Post by parityboy » Sat Jul 19, 2014 3:46 pm

@marzametal

Not really. Even with incoming ports, the packets are NAT'ed down to non-routeable private addresses anyway, and typically only one port is exposed per connection (and therefore typically one application). Obviously if that application is a server of some kind (like Apache) and has a vulnerability, that can be exploited as it would on the clear Internet, but that's a software issue rather than a networking issue. The main issue with port forwarding, from a CryptoStorm point of view, is that ports have to be assigned to accounts.

There are no accounts on CryptoStorm, which is the whole point. :)

Ignore that last part, it's rubbish. I've just remembered my experience with VyprVPN. There were no ports assigned to accounts, but there were many exit addresses to choose from, so there was a greater chance of a free port on a given exit. However, part of Cryptostorm's security model is to have large swarms of traffic flowing through relatively few exits, providing a mask for network members.

Locked