Question about Soulseeks network behaviour

Submitted by nqBW on Sat, 04/23/2016 - 02:34
Forums: 
Soulseek General Discussion

Hello everybody,

i wanted to start using soulseek, but i noticed some questionable things about soulseeks behaviour regarding the network communication.

I use the following platform:

Windows 10 Enterprise x64 fully patched
SoulseekQT-2016-1-24 (tried the older release linked on this site too)
Asus AC68U router with current firmware
16 mbit ADSL internet connection

Using the tcpviewer from sysinternals i noticed that the soulseek client seems to establish a vpn connection - at least the used hostnames hint to this direction.

And i noticed a lot of outgoing communication getting dropped by the firewall, although exceptions for the server and listening ports have been setup. The port forwarding is working properly as stated by the soulseek-website.

I read a lot of articles in this forum, where people suggested to use UPNP on the router - but this seems extremly careless to me.

The powerfull Router just cuts the internet connection when soulseek is used for some time or i start a search.

So i raise the following questions:

Is soulseek using an integrated vpn and if so - where does it connect to and what kind of traffic does it carry?

What firewall-Rules need to be setup, in order to establish a stable soulseek-connection?

Regards,
nqBW

Submitted by sammy123 on Sun, 04/24/2016 - 21:46.

Hi nqBW
thanks for the detailed infos
No SLSKqt is not using a vpn connect. Unresolved IP connects might be because of a bad DNS (or exactly a very slow reaction) resolve (which procexp64 relies on). The lot of connections comes from the swarm search mechanism of SLSK. uPNP is something I would NOT recommend apart from working properly only rarely it's a server world: do set things up clean and it will stay put.
I just answered the drop INet connect here (and a few times before):
http://www.soulseekqt.net/news/node/3517
your router just drops the connect (which is a bad behavior) as he gets flooded by lots of answers, postpone packets, drops some and gets an stack overflow. I work partly for the dd-wrt community and most router software of consumer grade is just not worth selling it. That's why there's a big market for alternative router OS in the P2P area. A good router does not drop the connect whatever he got to do. Dropping packets because of overload is OK, but staggering by working under high load is bad programming (which is usual in consumer grade due to the short "time 2 market" and lifetime prognosis of network stuff.
As long as your router does the port forwarding the right way (which is hard to tell, as when I sent a search it will contain my search term, my ip and my port where I listen, some clients answers on the wrong port and gets dropped; hell knows where they get the wrong port info from) and do not enable a flood control on that port it's OK. So no special rules needs to be set: just take everything from A to B. I'm currently working on a troubleshooting guide to SLSKqt with network settings just to clear out the basics of Server/Client working of (any) P2P systems.
Cheers

P.S.: Remember that procexp is only a momentary reflection and not for debugging (that's done by procmon), so you see only a part of the real doing. netstat helps as well, but is very unspecific who is doing what.