Thank you Thomas for your answer. Your voice is very helpful to me and uncovers other problems, and makes me realize I'm at the beginning of the path to solve it. Your right, that to solve this problem in general I need an application level proxy. But first of all I need to detect the traffic, even I would have a proxy I need to detect traffic. However, analysis of source and destination ports is not enough in this case. Additionally, even if I couldn't solve problem with masquerading of all protocols, some of them would be useful. Eventually, if I well detect type of the traffic I can prioritize it on the more expensive link. Thank you for answer again, and I think that similar problems with p2p software have many people, who should be able to full control the traffic and to do anything with it what they want. I don't know if there is a good solution for this problem now, but this is a good idea to enhance Linux possibility of routing in the near future, because this problem is growing. Regards, Luman >-----Original Message----- >From: Thomas Lussnig [mailto:lussnig@xxxxxxxx] >Sent: Tuesday, March 25, 2003 2:29 PM >To: Luman >Cc: 'Kim Jensen'; lartc@xxxxxxxxxxxxxxx >Subject: Re: [LARTC] Intelligent P2P detection > >Hi, >i think you will run at least into two problems. >1. You need and aplication level tool that will tag the packets >2. You can run with the masquerading into an problem since some P2P >software need to setup if they run behind masq. >3. Even if you fixed 1+2 you have not win >For eDonkey protocol i know that the back connection is not fixed to the >sender ip. Because eDonkey >support proxy connections it tell in the protocol on witch IP/Port the >answer (and file data) should be send. >That mean you have to do it real 100%, you need and transparent >aplication layer proxy. > >Other option is to give the p2p Clients own IP that are routed via the >cheap geateway. >Routing should not the problem since the packets are masqed you can use >source routing. >And for prio it depend if you router support TOS based routing. BUT >than you need to >take care that the clients do not send TOS with high_troughput on >unrecognized p2p conections. > >Cu Thomas
