Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: Transmission 2.80 Offers Up Various Changes

  1. #11
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by Kivada View Post
    It's still too simple, I'll stick to Vuze even though it's written in Java... It's still the only torrent app that doesn't completely oversimplify things.
    You might want to try ktorrent. It's pretty heavy on the features.

  2. #12
    Join Date
    Dec 2012
    Posts
    457

    Default

    Quote Originally Posted by c117152 View Post
    Sadly it seems the protocol itself doesn't lend to multiple instances running in the same machine. We've tried different loads and setups including foregoing all firewalls and security for the sake of testing. But, the clients just misbehaved and at rare cases even seg faulted. This wasn't just transmission but other implementations as well.
    I did not expect that. Did you run multiple instances with seperate users?

    Quote Originally Posted by c117152 View Post
    At first, there were forwarding issues since each instance needs to open a whole lot of ports and just doesn't scale over 2-5 clients depending on the number of active torrents. Already some gigabyte (expensive at the time) cards and switches were unboxed since the overhead started to build up across the lan. This was already in the works so it didn't raise the red light.
    Code:
    gebruiker@Delta:~$ lsof -i -a -p $(pgrep transmission)
    COMMAND     PID      USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
    transmiss 28001 gebruiker   17u  IPv4 3945341      0t0  TCP *:56070 (LISTEN)
    transmiss 28001 gebruiker   18u  IPv4 3945342      0t0  TCP *:50111 (LISTEN)
    transmiss 28001 gebruiker   19u  IPv4 3945344      0t0  UDP *:50111
    The 56070 port is for transmission's http viewer. Or are you implying other ports used for connecting to other clients? Perhaps you need to tweak the TCP stack (yes, this would not be optimal).

    Quote Originally Posted by c117152 View Post
    Then, we had some initial success with layer 2 switches to favor http and ftp per machine and establish quotas. But much of the network wasn't l2 so cost was unacceptable.
    So I guess that HTTP and FTP are used so much since there are layer 2 switches for those... Makes sense.

    Quote Originally Posted by c117152 View Post
    Since we're not an open network, we decided to try and manage each client's machine separately instead. This already is something most companies wouldn't do. Never the less, we tried down regulating and limiting individual clients in each machine; To say, 10 peers per torrent and 50 overall connections and other figures. But, it either bottlenecked the network to the point that nothing was downloading and you couldn't even surf the web, or it killed the torrenting specifically.
    Did you try to use kernel throttling? (tc). Throttling the amount of peers will not reduce congestion, only overhead (I think).

    Quote Originally Posted by c117152 View Post
    I even clearly remember the one setup that seemed to work, only the CIFS turned out unusable... Just weirdness all around. And mind you we weren't just doing just the usual amateurish protocol analyses. One of the guys was an ex signal processing dev and he run all sort of strange voodoo trying to figure out what was wrong. He's actually the one that said that the "peer in p2p means a separate lan ip". When I suggested a single daemon on a dedicated machine for the lan-wan with FTP-like user privileges. The decision was against it since the advantage versus FTP was not applicable for such a small firm. Obviously, I ignored the "decision" and went ahead to try and set it up only to discover that while many FTP daemons had their own optional user management, the bittorrent daemons did not.
    If "peer in p2p means a seperate lan ip", why not assign multiple ip's to a single NIC and try that? Maybe that is a solution. I'm genuinely surprised that setup is not working...

    Quote Originally Posted by c117152 View Post
    TL;DR: Been there, failed that. Like Samba and the various FTP servers (ProFTPD comes to mind), virtual users are necessary for more complex networks. It's the same pros\cons, and it's just as necessary. I suspect there is a way to still pull off a couple of daemons on the same physical machine, but I'm not convinced it will scale with firewalling and security without some real hardware costs. Still, I'd like to see a working setup...
    I guess that samba and ftp servers are more developed to this regard. You just found out the hard way :/

  3. #13
    Join Date
    Mar 2013
    Posts
    144

    Default

    Quote Originally Posted by Rexilion View Post
    I did not expect that. Did you run multiple instances with seperate users?
    It was a while back but from what I remember a group of users called trans1 trans2... trans12 so probably yes.

    Quote Originally Posted by Rexilion View Post
    Code:
    gebruiker@Delta:~$ lsof -i -a -p $(pgrep transmission)
    COMMAND     PID      USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
    transmiss 28001 gebruiker   17u  IPv4 3945341      0t0  TCP *:56070 (LISTEN)
    transmiss 28001 gebruiker   18u  IPv4 3945342      0t0  TCP *:50111 (LISTEN)
    transmiss 28001 gebruiker   19u  IPv4 3945344      0t0  UDP *:50111
    The 56070 port is for transmission's http viewer. Or are you implying other ports used for connecting to other clients? Perhaps you need to tweak the TCP stack (yes, this would not be optimal).
    Each connected peer establishes another socket on another port so under real world usage it builds up. On my personal home machine I've seen 3 active torrents reaching well over 150 connections. Now, on paper the hardware should be fine, in reality even mid-end switches won't handle something like this let alone the low end ones.

    Quote Originally Posted by Rexilion View Post
    So I guess that HTTP and FTP are used so much since there are layer 2 switches for those... Makes sense.
    I suppose. I never bothered with the whys

    Quote Originally Posted by Rexilion View Post
    Did you try to use kernel throttling? (tc). Throttling the amount of peers will not reduce congestion, only overhead (I think).
    The l2 hardware was the second QoS step. The throttling was there first. But that was the signal guy's job so I didn't bother going into to much details there...

    Quote Originally Posted by Rexilion View Post
    If "peer in p2p means a seperate lan ip", why not assign multiple ip's to a single NIC and try that? Maybe that is a solution. I'm genuinely surprised that setup is not working...
    tap1 tap2 tap3... Yeah. I think that was done as well. Not sure what went wrong there though. It was a while back...

    Quote Originally Posted by Rexilion View Post
    I guess that samba and ftp servers are more developed to this regard. You just found out the hard way :/
    It was fun Besides it was an important learning experience. I always was a big proponent of the *nix's small programs working well philosophy. But seeing it break apart made me realize something wasn't quite working right there.
    Eventually I've learned about Plan9 and how this sort of issues were addressed from the bottoms up in the kernel, protocols and even user land. It's the reason I'm fine with systemd. Sure it's not *nix like sysvinit, but *nix isn't all bed of roses either so maybe an out of the box solution is just what it takes.

    Anyhow, I'm sure one day someone will build on either bittorrent or some other p2p protocol an enterprise solution. GIT vs. CVS is sorta the same idea so it's not too unlikely...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •