aMule Forum
English => Feature requests => Topic started by: FreeToGo on April 13, 2007, 01:05:16 PM
-
Is there any chance to have amule-mod Xtreme? eMule-mod Xtreme is very popular. Is there any chance to port it to amule?
http://www.emule-mods.de/?mods=xtreme
-
Xtreme will never be ported to Linux/Multiplatform. And I doubt there are any features _really_ worth to be included in aMule.
Prove me wrong - request features which ou miss in aMule which Xtreme has.
-
Reask sources after IP change
- after emule detected a new client-IP, it inform all you sources immediately of your new IP. So you don't loose any waiting position
- remark: it only works if you connect to a server after IP-change!
http://www.emule-mods.de/?mods=xtreme&show=details
-
xtreme mod splits the emule dev community, who believe its a bad mod with bad features
i agree with this...bad mod.
IMO, features aMule needs:
ClientAnalyzer CS-
New-Age Leecher Protection - punish only real bad users and not randomly whoever you might not like! (unlike xtreme mod which bands hundreds of mods without knowing if there good to the network or not... bad system!!)
Better upload tuning-
you can enter a desired datarate per slot or use slotfocus to concentrate your upload on as few clients as possible (better support for releasers and better optimization for diffrent upload speeds)
IP2Country-
In nearly every window a flag will show where the ip originates. (not a must, but very informative)
IntelliFlush-
An enhancement of the filebuffer system. Once activated you can raise the filebuffer up to 30MB per file and adjust the time after which a flush will be forced. IntelliFlush will flush automatically whenever you complete a chunk so you can share it ASAP. (makes the buffer fairer/faster and takes load of your I/O)
Auto Hard Limit-
Automatically sets a file's hard limit to the highest needed value. This denies a file which has only 10 sources from getting a HL of 250; the other 240 sources can now be swapped to other files.
SafeKAD+KADHelper-
Additional security checks for Kademlia including anti-fragmentation of KAD packets improve the security and functionality of the Kademlia network.
Save/load sources-
Automatically save found sources which are immediately available after a restart.
Infinite queue-
Infinite upload queue (when a clients upload queue is full, there is a massive amount of overhead to tell them your full then to disconnect them, also, they will keep reasking you untill there is a free slot, this causes pointless overheads.
A larger queue does not result in a larger overhead for managing this queue. Neither the number of connections nor the connection overhead will be increased by a larger queue.
PowerShare-
You can set files to be powershared by right clicking them in the shared files list and selecting "Powershare" -> "Set powersharing". Files that have powershare activated will be uploaded a 100% of the time, if there are people trying to download them. It doesn't matter how many other files you share or download. This makes it possible for you to release files efficiently, and still download files normally. If the files with release priority doesn't use all the bandwidth, normal shared files are uploaded. This means that you won't have to unshare everything that you are not releasing. This gives more sources for files on the network, and make sure the allotted upload bandwidth are always used a 100% efficiently to release your files.
Download/Upload/Connections Wizard-
better settings, better upload, lower overhead, better overallnetwork.
Remove auto dropping of source-
in fact remove manual dropping!!! this creates extra reask overhead of sources you have already dropped which adds more overhead to the network, bad bad feature.. go away!!
-
As long as you reask within ~ an hour, you will not loose your position in the queue. aMule will reask within about 30 minutes.
30min < 60min -> you keep your position in the queue -> feature is not needed and causes unnecessary overhead.
---
Wizard's Tombstone was very interesting, but no matter how good an anti-leecher system is in the end: You'll accomplish very little and in most cases you create an unfair client. (As Xtreme might be.)
Won't be included. (Anti-Leecher systems have been requested before, hence I know this answer for sure.)
---
desired upload rate per slot is default in aMule
---
I think IP2Country might be included - as long as someone codes it and so far no one did it.
---
I don't know about the current buffer system nor about Kad.
---
In aMule release priority is similar to PowerShare.
---
There's nothing you can do against user stupi... inexperience. An assistant won't help someone who doesn't know what internet connection he uses.
---
I strongly agree to removing source dropping. I'll request this in the bug tracker.
-
http://www.emule-mods.de/?mods=xtreme&show=details
[...cut...]
-
on the upload tuning i was maining on about using 'slot focus', instead of using set KB's slots (which doesn't really work for high speed uploaders i.e. over 300kb)
but yeah... having a tickable 'Use slot focus' which disables the 'per slot control' thats in amule now, would be super..
from ZZUL's eMule mod...
ZZ SlotFocus: Focus the upload bandwidth to as few upload slots as possible!
(only one, if the top slot wants it all). Transfers files to fewer people at a time, but faster to each. Faster transfers makes chunks complete sooner, making it possible for other clients to share the chunks sooner. This gives more sources in shorter time, sharing the upload demands on several computers sooner. At 76 Kbytes/s ZZUL opens ca 6-10 slots, when official eMule opens 24 slots. ZZUL only opens new slots if necessary to use the configured bandwidth. Upload slot focusing version 2 is available in this patch. Version 1 is used in eMule Plus (and others?). You can see which upload that has the highest priority by checking the number in the "Slot #" column. Slot #1 get all bandwidth it can handle. Slot #2 gets any leftovers after slot #1 has taken what it wants, etc.
When you download a file, it is good for you to give all chunks you already have of that file to other clients as soon as possible. As soon as you have spread your chunks, the other clients will actually help you to download the chunks you are missing. Then you can get those chunks from them (and fast, since you now have good credits with them). It will also be easier for you to get the chunks from the original source, now that is no longer busy uploading chunks that you already have, to other clients. So set your upload speed as high as possible!
I agree, there should not be too many 'choices' because too many options equal too many varibles to those options, which harms the overall network, which is happerning currently in the official emule mod releases. i.e. options like 'hideOS' some mods like Stulle bring out 'anti-hideOS'.. soo its a never ending battle.
Mods can be great but the fact of the matter is, if everyone used default client no one could complain about bad features because every1 would be the same.
ohh thank you 'FreeToGo' for spamming the board.
-
Sorry for spamming the board in case anyone think that I am
Anyhow, I found a good sources of information that might be of interests for those seriously want to pursue their features' quest.
http://en.wikipedia.org/wiki/Comparison_of_eDonkey_software
-
I would like to add my 5cent to "upload bandwidth" discussion.
All applications that need to regulate their upload bandwidth face the same problems.
True, and solution is known. Actually, there's several solutions.
* OS lets application know when data is passed to protocol layer. Either thru blocking send() or thru select() interface. So, theoretically speaking, application have an idea about rate of data going from transport layer into protocol (from TCP to IP). Which means that there's no need to "measure" rate in any bizarre way proposed here (pings, Ethernet stats etc). They all wrong, no exceptions.
* In Linux OS user can turn on packet queueing and classification (see man tc). In this case, OS itself may limit traffic of particular type. And yet again, rate which application "see" will be affected and therefore noticed.
Conclusion: aMule need to measure how fast outgoing socket becomes writable (in Linux terms) in order to know it's actual upload capacity. IIRC this is already implemented.
-
Conclusion: aMule need to measure how fast outgoing socket becomes writable (in Linux terms) in order to know it's actual upload capacity. IIRC this is already implemented.
Once aMule could measure how fast outgoing socket becomes, aMule should only opens new slots if necessary to use the configured bandwidth.
-
... which is what it does.
-
aMule does bandwith management quite poorly up to date.
1) Channel can be variable-bandwith.Is this case handled properly?
2) Some channels, even with static bandwith, have high ping latency when saturated.This suxx since www browsing drops to speeds of dialup when this happens.Now imagine the following: aMule set up to use 80% of channel capacity.To keep ping good.Now, we're sending file through IM client, uploading to FTP, etc "out of band" for aMule.Let's assume this eats 50% of bandwith.Now what?My channel will not become 130% faster of course, but rather will become overloaded and 100% used.Ping will get quite high, making even WWW browsing as slow as dialup, loss of sources, worse Kad maintenance, etc.Preferred scenario is that aMule is to detect high ping and temporarily drop upload (and maybe download) speeds to keep ping low, then resume on full allowed speed when channel no longer used.But now this is not a case.This works quite well with eMule mods implementing pinging.As for aMule, I can only lower aMule's TCP packets priority on router but it is pain in the ass to configure (average Joe will 100% fail to do so) and it's still quite poor solution (what an ugly hack!) anyway.
P.S. I have to admit that internet channels are differ greatly on their behavior depending on technology, settings, etc... so this is not too smart to assume that if something works OK for you will work greatly for everyone else.Same applies to Kad.Instead of dumb mumblings that Kad code is "the sacred cow" why not to discuss things with eMule dev's? Sorry, just an opinition, please do not treat this as offence.
-
I do discuss things with the eMule devs. Kad is still sacred.
As for the scenario you propose up, why is your FTP client not doing the bandwith control?
-
As for the scenario you propose up, why is your FTP client not doing the bandwith control?
I guess aMule though coined as a client is running more like a "service". It is better to let aMule play nice so as to encourage people to leave it "on" all the time.
Talking of playing nice, linux got a command called nice to schedule process priority. I wonder if there is anything similar but to schedule bandwidth priority.
-
lfroen told you to check tc.
Also, there is no way for aMule to actually control congestion, more than it already does.
-
I do discuss things with the eMule devs.
Great to heard.
Kad is still sacred.
Code is not a cow :P.And .. er .. excuse me for shooting to the legs but CVS version has broken Kad which connects, etc but ... fails to find sources :'(
As for the scenario you propose up, why is your FTP client not doing the bandwith control?
Yep, true up to some degree.But as for me, I do prefer aMule to slow down while I'm uploading to FTP.So, FTP client do not have to throttle.And what about IM clients?And other software capable of sending data?It should implement hardcore bandwith management?Why?IM client for example transfers files only occasionally.It is not its main speciality.From other hand, aMule always transfers files so it is reasonable to expect it will operate like a pro when doing so, right?As for me, filesharing occurs in background and should not interfere with day-to-day tasks if possible.Now, it sometimes does.
Using tc ... well, my ADSL router has it built-in ("hacked" advanced firmware), it is pain in the ass to configure it and it solves problem only partially, because tc isn't damn effective when managing outbound 256Kbit channel with 1492 bytes packets(there is just too few packets to have enough freedom of maneurs for tc).Also some hint: if someone shares internet channel on router and router is not runs traffic scheduler (most common case), tc on local machine is quite useless: it can not account fact that other machines transferring data via same channel so tc will fail on such "semi-dynamic bandwith" channel because local tc is not aware how many bandwith left unused on the router.Of course tc on router solves this but you do not have to expect this hack (er, you call this "solution") will be widely used :P
In fact. there is two machines, each can run aMule.As well as both.As well as any other software.They sharing same ADSL channel.Now, it a bit relaxed with tc on ADSL router (quite uncommon case, 99.99% users will fail to repeat this trick since this requires "hacked" firmware!).However 2 eMules with bandwith management based on pinging are working a way better than this complex and half-working "solution" in given network setup.Even if 2 eMule running they just throttling upload speed when needed and never saturating channel so it getting high latency.As well as balancing channel load on their own, etc.So, ping-based bandwith management is NOT so moron, even if it looks so for someone.
-
... dude.
I said that millions of times.
aMule can't ping.
You can only ping as root.
-
And, just to have it comlete, ping is ICMP, and I, and I think many many others, too, don't even think about natting icmp-ping just to use aMule.
-
... dude.
I said that millions of times.
aMule can't ping.
You can only ping as root.
Umm, just pinged some host as... er, usual user using "ping" command.Am I doing something wrong here?It just works while I'm not root.
Possible you're about UDP ping?And even if you need to allocate some port below 1024, it is possible to start as root and then drop root rights when socket allocated, just set gid and uid to normal restricted user (that's how some daemons creating privileged sockets without being run as root later).
And, just to have it comlete, ping is ICMP, and I, and I think many many others, too, don't even think about natting icmp-ping just to use aMule.
Wast majority of NATs and firewalls are usually allowing outgoing ICMP pings and replies to these pings and handling them properly.Just 'cause without ping any network troubleshooting is sort of nightmare.Usually this even requires no extra setup (for example, all SOHO routers I seen are allowing outcoming pings and replies and handling this properly).And no, I did not offered that this should be the one and the only option to control speed.Those rare people with their (pretty unusual) NATs\firewalls incapable of dealing with ICMP can fallback to static speeds setup (though I can not understand how these guys are troubleshooting their network, just in case).What's wrong?And well, there is also UDP ping as option.You're already NATing UDP to run aMule, yep?Finally there is another sort of similar system - it measures round-trip times without sending any extra packets.As for me, this worked worse than ping and this requires lots of peers to get proper statistic and inaccurate due to remote peers can have latency on their own.But even this still works somehow better than dumb flooding at full speed and complete ignorance of channel saturation.
-
... dude.
I said that millions of times.
aMule can't ping.
You can only ping as root.
Umm, just pinged some host as... er, usual user using "ping" command.Am I doing something wrong here?It just works while I'm not root.
Possible you're about UDP ping?And even if you need to allocate some port below 1024, it is possible to start as root and then drop root rights when socket allocated, just set gid and uid to normal restricted user (that's how some daemons creating privileged sockets without being run as root later).
Don't talk about things you don't know about, please, it's embarassing. You can't use raw sockets as user. The ping binary is setuid root. And no, I will not encourage people to run aMule as a priviledged service, even if it would be latter dropped. The security risk is too high.
-
Don't talk about things you don't know about, please, it's embarassing. You can't use raw sockets as user. The ping binary is setuid root. And no, I will not encourage people to run aMule as a priviledged service, even if it would be latter dropped. The security risk is too high.
Er, I was somewhat lame, sorry.But btw, let's remember there is UDP ping (I guess it is ok to use local high udp ports, right?) and round-trip times can be measured as well(this requires nothing at all but not as good as real pinging and requires some number of peers to have realistic statistic).
P.S. when choosing between security and usability I'm choosing a ... balance.I do not want to feel myself like locked in the jail just to be a bit more secure.As long as program drops rights on startup after sockets were allocated I see no ways how it can harm me more than today when it runs as non-root, maybe I'm wrong (I'm unfortunately not a expert in Linux\*nix yet) but lots of security-sensitive daemons do the trick with setgid\setuid and it seems to work providing good balance between security and functionality - program does what it should and able to allocate ports, etc but it does not runs as root most of time.
P.P.S. dropping of rights about to occur quickly on startup and before any actual networking will take place, etc.So, it looks like it's only you who can harm system while aMule initializes with root rights.You can harm aMule users already, if you will ever wish to, because I have to run "make install" as root anyway and it is doubtfull that lots of users carefully checks what actually will happen when you issue this command.
-
Wast majority of NATs and firewalls are usually allowing outgoing ICMP pings and replies to these pings and handling them properly.Just 'cause without ping any network troubleshooting is sort of nightmare.Usually this even requires no extra setup (for example, all SOHO routers I seen are allowing outcoming pings and replies and handling this properly).
Almost all guys that maintain firewall, and almost all howtos for iptables and other things that claim to be more than a personal Firewall for Windows, and that isn't enough, because I do it that way, have one thing in common. They think, that the best policy for a Firewall, Paketfilter or what you like to call it, is: Disallow erverything, and allow then what you need. You are again talking about things you don't understand, and the fact that most SoHo-Routers are shipped misconfigured or unconfigured and you aren't able the change this doesn't tell anyone that this is the right way.
I can not understand how these guys are troubleshooting their network, just in case
I don't want to repeat Kry or myself, but just don't talk about things you don't understand. When there are network troubles and ping is needed, it will be allowed, if not, it is disallowed. And if you use ICMP or UDP makes no difference because every port that is opend/natted or whatever different from closed is a possible security hole that can be avoided.
You want to surf, you can slow down or shutdown aMule by Hand.
-
Also, ping... ping what? what should we decide to DDoS from aMule?
-
Almost all guys that maintain firewall, and almost all howtos for iptables and other things that claim to be more than a personal Firewall for Windows, and that isn't enough, because I do it that way, have one thing in common. They think, that the best policy for a Firewall, Paketfilter or what you like to call it, is: Disallow erverything, and allow then what you need.
Absolutely!So, those who firewalls all things (including things they're need to use) have to unfirewall things they're need.Nothing wrong here.If you need ping, do not firewall it or unfirewall it if you already firewalled it.F__kingly simple conclusion, don't you think so?
You are again talking about things you don't understand, and the fact that most SoHo-Routers are shipped misconfigured or unconfigured and you aren't able the change this doesn't tell anyone that this is the right way.
Hmm, sounds like typical "all people are idiots and I'm the only smart guy on this planet, blah-blah-blah".Who except you actually cares how do YOU treat these settings?These settings are here, they will be here for a while and defaults will prevail anyway, no matter what you think about it.Even corporate firewalls are often allowing outcoming pings and replies to these pings.And SOHO routers do this as well.They only killing incoming ping requests.Seems to be reasonable balance.Firewalls are basically intended to protect from hostile outside environment, and not to cause lots of headaches to its legitimate user(s) by turning from bastion intended to protect into fortified jail intended to restrict.
Yes, If you feeling paranoid you're ok to spend whole life locked in the underground bunker.But don't be surprised that other people will find this ... er... a bit strange or inconvenient to spend whole life being locked in the bunker, even if this provides some extra security.
I don't want to repeat Kry or myself, but just don't talk about things you don't understand.
Excuse me, but paranoids and fascist admins are not seems to be a good judges.Especially taking into account simple fact that fascist network setup with outbound ICMP disabled is very rare in the world.And well, usually in fascist environments admins are firewalling P2P a way before this happens with ICMP.So you're basically talking about nothing.Or, about your specific network setup.Not very interesting thing anyway.
When there are network troubles and ping is needed, it will be allowed, if not, it is disallowed.
If you're so paranoid, you're better to approve each sent P2P packet manually as well ;D.You can even craft rule for packet and later ...er... delete it.The only prob is that you should do all this really quickly ;).But again, you do not have to expect others will do the same.
In real life you probably will have a quite open ruleset for outbound packets when running aMule anyway.Probably you have to allow any DST and DST PORT in some places, yes?Or you're crafting rules for each remore peer individually, adding few millions of rules to your firewall?What if Alice is on address X, port A, Bob on address Y, port B, John on address Z, port C, etc?... I only see solution to allow aMule outcoming packets to any DST ip and any DST port at very most restricting SRC IP and SRC port.So I see no gain in security if outcoming ICMP is disabled or enabled for aMule process.
So, what is your problem?If you don't need this solution I do not insist you should allow ping on your firewall and use it.I'm pretty sure this option should be configurable and there should be way to disable it since there is no universal shit in this world and feature can make someone unhappy (for example, on high-latency channels or channels where ping not increasing too much on channel saturation).
And if you use ICMP or UDP makes no difference because every port that is opend/natted or whatever different from closed is a possible security hole that can be avoided.
You want to surf, you can slow down or shutdown aMule by Hand.
Do it yourself please.As well as approve each and every P2P packet by manually crafting rule to pass packet and then when it passed, delete your rule.Actually you don't even need a firewall since you can takeover this role and approve all packets yourself.
And well, what should I do if there is more than one user on the router?Asking mother\sister\brother\boyfriend\girlfriend\wife\husband\dog\cat\mouse to throttle their aMule just because I want to surf is pretty annoying option, don't you think so?(if no, go on and inspect each packet yourself:-\).Mods of eMule with pinging are pretty self-balancing.But not a case with aMule though :'(
Also, ping... ping what? what should we decide to DDoS from aMule?
If you will ask me what to ddos, I will offer some anti-P2P companies for example, RIAA seems to be good target ;).As well as these nasty P2P poisoners\flooders ;D. But well, enough kidding.Instead of attacking me, maybe you're better about to take a look on any mod implementing this pinging and learn how this implemented?As far as I can guess it usually pings closest available IPS's router (this surely enough to track channel saturation and provides proper results while avoiding ddos).Such router usually have to pass all my data anyway, some small and rare pings are nothing compared to all my dataflow.
-
paranoids and fascist admins
Please be polite and do NOT insult anyone.
Reminder: You are here to request features you want to see in aMule. NO ONE is going to do anything if you take the code, write these features and follow the GPL when publishing, (unless you harm the network)
But in order to persuade our fascist admins (read: main developers) it's of no use to insult them and other forum members (no matter how much of an asshole they are), but instead to answer their questions.
Also, ping... ping what?
The ISP.
-
Let's start with
http://en.wikipedia.org/wiki/Fascism
and then move back to the point where you can't ping unless you're root.
-
Absolutely!So, those who firewalls all things (including things they're need to use)
You got it, it is NOT needed.
"all people are idiots and I'm the only smart guy on this planet, blah-blah-blah"
No, that's Kry, I just try to follow him.
Even corporate firewalls are often allowing outcoming pings and replies to these pings.And SOHO routers do this as well.They only killing incoming ping requests.Seems to be reasonable balance.
Coll, so you can ping anyone you want. But don't forget, for them your pings are incoming ones and they'll never know about it. So you want to send requests but don't expect answers to measure something. That's no problem, but the result can be hardcoded. It will be 0.
In real life you probably will have a quite open ruleset for outbound packets when running aMule anyway.
Exactly 6 rules are enough.
Probably you have to allow any DST and DST PORT in some places, yes?Or you're crafting rules for each remore peer individually, adding few millions of rules to your firewall?What if Alice is on address X, port A, Bob on address Y, port B, John on address Z, port C, etc?... I only see solution to allow aMule outcoming packets to any DST ip and any DST port at very most restricting SRC IP and SRC port.So I see no gain in security if outcoming ICMP is disabled or enabled for aMule process.
First I thought you know what a firewall is. You filter for src/dst - port/ip with protcoll and some other criterias. Nothing more, nothing less. If you want to allow connections for processes, you need a Desktop"Firewall" (something like Zonealarm) But these things shouldn't be called so. Just code a NOP-Sled in a endless loop and you have the same effect (at least if you are not missing the fancy icon in your systray).
And well, what should I do if there is more than one user on the router?Asking mother\sister\brother\boyfriend\girlfriend\wife\husband\dog\cat\mouse to throttle their aMule just because I want to surf is pretty annoying option,
What you should do is more than simple. Learn what a firewall is, how it works, and how to configure it, and use traffic shaping.
-
paranoids and fascist admins
Please be polite and do NOT insult anyone.
I'm using same conversation style as my opponent.If he is willing to "label" me with "sticker" ("you're stupid, you don't know, blah-blah"), I can do the same.If someone does not likes it's own conversation style, he has to reconsider it.I will do the same then.
Reminder: You are here to request features you want to see in aMule. NO ONE is going to do anything if you take the code, write these features and follow the GPL when publishing, (unless you harm the network)
Yes, exactly.However, it is still a feature request forum so at least I can try, isn't it?
But in order to persuade our fascist admins (read: main developers) it's of no use to insult them and other forum members (no matter how much of an asshole they are), but instead to answer their questions.
Actually, it was not intended as insult.This phrase was just used to show that security only good up to some degree and you always have to find balance between security and usability.The most secure way is to ban 0.0.0.0 - 255.255.255.255 and unplug network cable for better reliability.However this is hardly a usable solution.And well, if someone feels himself like a fascist (or why he applies this phrase to himself, then?), thinks it's bad (or why this is treated as insult?), maybe, he has to change something in his life? :o
Let's start with
Nope, fascists are not my feature request, sorry.And well, I already told about pinging.Try to read again, you don't have to be a root in all cases.If you do not want to implement feature for any other reasons (for example you do not need it since all works ok for you without it, etc) it is ok. However, I'm pretty sad to heard comments about aMule like "why it saturates channel and all getting so slow?eMule was better!".I'm actually want to see Linux winning the battle.Not just to heard once more from users that "linux software worse than windoze-based one, blah-blah".I do not want to hear user's comments like "windows was better" and "all good software is for windows, there is no good software for Linux!".
You got it, it is NOT needed.
It is not needed for you and in your network setup.Great.You can relax, have some beer, etc.So, why you're here, at all, then?In my network setup pinging works better than static setup.For those who can't get the clue, try to read direct text: THIS HAS BEEN TESTED WITH EMULE MODS IMPLEMENTING SUCH PINGING.And I liked how this works.That's why I'm requesting feature.Can you understand this, after all?Of course nobody is "strictly must" implement this.But I'm surely can admit I like how this feature works in eMule in my network setup.
Coll, so you can ping anyone you want. But don't forget, for them your pings are incoming ones and they'll never know about it. So you want to send requests but don't expect answers to measure something. That's no problem, but the result can be hardcoded. It will be 0.
Duh, only pretty dumb people can ping firewalled machines for a long time, I guess.And well, if you'll stop attacking me, will take a look on mods implementing this feature, try to ping like they do, etc... well, the practice shows that in most cases mods are able to find reasonable close host to ping.And no, there is not 0 replies.Why?Try to read RFCs related to IP networking, this helps.Some "fascist" network setups may be not a case.But actually, ICMP is not "just one more thing to ban", it used for variety of legitimate reasons and part of standard.If someone want to ban it, ok, he can.But he has to recognize consequences.Maybe someone has forgot but ICMP was not invented for hackers.It has a dozen of legitimate uses it was invented for.Try to read some RFCs related to IP networking, not just rule your firewall and blame me here ;)
First I thought you know what a firewall is.
First, I thought you read some RFCs related to IP networking but it looks like you're not.So what?If you'll read RFCs, you will figure out that I can expect ICMP to work in usual case, for example.I'm do not care about fascist setups.There is standards.That's all what really matters.If someone willing to ignore them, that's their option but they do not have to complain about some things not working in their setup then.
You filter for src/dst - port/ip with protcoll and some other criterias. Nothing more, nothing less. If you want to allow connections for processes, you need a Desktop"Firewall" (something like Zonealarm)
Hey?IPtables can allow access taking into account PID (GID, UID, ... - read man iptables for example).Do not know if I can call it "Desktop"Firewall"" but the option is still here.Of course this works only with IPtables on local machine where process resides, since you can't transfer information like PID over IP.So, remote firewalls have only packet headers to chew on and yes, there is no info about processes.Umm, well, you tried to say "all people are idiots..." once more here?Looks like it failed, sorry ;D
But these things shouldn't be called so. Just code a NOP-Sled in a endless loop and you have the same effect (at least if you are not missing the fancy icon in your systray).
Iptables has no icon in system tray on it's own.But will you blame it as well?Since it can take a things like PID into account and therefore making per-process rulesets possible (as long as it runs on same machine where process resides of course).
What you should do is more than simple. Learn what a firewall is, how it works, and how to configure it, and use traffic shaping.
Well, for those who has problems with reading I will repeat:
1) Local traffic shaping on my machine will not help since there is more than one machine attached to router and local shaper is simply not aware how other machines are using channel at given moment.Simple, yes?For example if my machine runs aMule and someone on other machine browses, shaper on my machine will have no idea that someone is browsing.Shaping will not happen.
2) My ADSL router runs (Linux) altered firmware with "tc" traffic shaper built in.It relaxes things a bit but this is half-working and quite complex solution.I will repeat again: tc isn't damn great on 256kbit upload channel filled with 1492 bytes packets.And well, in my opinition this is not a solution but a dirty half-working hack which compensates lack of settings in aMule.And I can't recommend everyone to hack their routers to have tc running on router itself so it able to account ALL traffic from ALL machines.This requires firmware flashing and unsafe for "average Joe"
P.S. Uff, I'm tired on flaming.Maybe we should discuss features, not our networking knowledge?
-
There have been a good technical discussion on "ping". Let talk about whether the majority linux users could possibly use this function safely.
I knew that some linux system required privileged access to run "ping" and firewall could sometimes prevent ping from functioning properly.
But what I don't know is what is the situation of the majority linux users of amule. Based on distrowatch, the most popular distros nowadays are Ubuntu, OpenSuSe and Fedora. In Ubuntu, ping doesn't require root privileges. For Opensuse and Fedora, inputs from others are needed.
I see ping based bandwidth control as an good options for amule users. As long as it is an option, it should be able to let users decide for themselves whether they want to enable it or not. Firewall and Root privileges could prevent some users from using these proposed the new feature. But I still think that it is good to have this option if the majority could benefit from it. And most importantly, I want amule to be the best linux ed2k client.
-
...
YOU CAN'T PING WITHOUT BEING ROOT, FOR FUCKS SAKE
YOU CAN'T.
CAN'T.
NOT ON UBUNTU, NOT ANYWHERE. YOU CAN'T.
THE PING BINARY IS SETUID ROOT.
PINGING IS NOT AN OPTION
READ MY SENTENCES.
-
Correct me if I am wrong.
That's is what I get
jc@jc-desktop:~$ uname -a
Linux jc-desktop 2.6.20-15-lowlatency #2 SMP PREEMPT Sun Apr 15 07:39:03 UTC 2007 i686 GNU/Linux
jc@jc-desktop:~$ ls -l /bin/ping
-rwsr-xr-x 1 root root 30848 2007-03-05 12:25 /bin/ping
jc@jc-desktop:~$
jc@jc-desktop:~$ ping yahoo.com
PING yahoo.com (66.94.234.13) 56(84) bytes of data.
64 bytes from w2.rc.vip.scd.yahoo.com (66.94.234.13): icmp_seq=22 ttl=52 time=163 ms
--- yahoo.com ping statistics ---
22 packets transmitted, 1 received, 95% packet loss, time 21005ms
rtt min/avg/max/mdev = 163.752/163.752/163.752/0.000 ms
jc@jc-desktop:~$ ping yahoo.com
PING yahoo.com (216.109.112.135) 56(84) bytes of data.
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=1 ttl=50 time=236 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=2 ttl=50 time=236 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=3 ttl=50 time=235 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=4 ttl=51 time=237 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=5 ttl=51 time=235 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=6 ttl=50 time=234 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=7 ttl=50 time=235 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=8 ttl=51 time=235 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=9 ttl=50 time=235 ms
64 bytes from w2.rc.vip.dcn.yahoo.com (216.109.112.135): icmp_seq=10 ttl=50 time=236 ms
--- yahoo.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9005ms
rtt min/avg/max/mdev = 234.989/236.020/237.834/0.827 ms
-
I'm using same conversation style as my opponent.If he is willing to "label" me with "sticker" ("you're stupid, you don't know, blah-blah"), I can do the same.If someone does not likes it's own conversation style, he has to reconsider it.I will do the same then.
Please be polite and do not insult anyone. (or do it at least in an intelligent=hidden fashion)
Else today will be my monthly troll day.
OK, let's start over again with the ping thingy:
aMule is a multi-platform program. You can NOT rely on the availability of a ping executable, but you have to use your own implementation. Hence, it doesn't matter what fancy things your Linux system can do as long as e.g. Windows cannot do this.
In contrast to windows, on Unix systems the first 1024 ports are reserved to root and cannot be easily used by normal users.
Short explanation of *nix terms: "setuid root" - the binary will be executed with the rights of the owner of the binary - root owns ping, thus ping has the rights of root.
Now there are solutions (like e.g. Apache IIRC) who start as root to reserve the ports and later drop rights, but this is not possible for aMule as you would need ping rights the whole time.
The only thing I can imagine is a single thread with the necessary rights, but I don't know if that's easily and securely possible.
-
THE PING BINARY IS SETUID ROOT.
Kry, don't be nervous please.That's not what I'm want to achieve.Well, YES, I READ YOUR REPLY ABOUT PING AND SUID, UNDERSTOOD IT, CHECKED IT and even agreed that I was wrong and lame.So there is no need to repeat this.But did YOU read my comments?I did listed other options, see above.
1) Probably aMule can start as root, create this damn priveleged socket, drop root rights with setuid and setgid and go on as normal unprivileged user.At least that's how security-sensitive daemons like http servers are working and almost nobody complains about their security.
2) UDP ping seems to be an option.Mods are using it as well.We probably can use high local UDP ports so we do not have to be root to do UDP pings.
3) Finally as poor but no-overhead, no-security-crap and no-any-new-fuc__ing_sockets solution you can measure roundtrip times.This solution has certain drawbacks but still better than no any flow control at all.This thingie called SUC if I'm remembering well (Smart Upload Control).
So, as for me looks like there is plenty of options.Another question is if you're do not like feature or just do not want to implement it.This is surely OK since you're not a my personal slave - I can just OFFER some feature, you can reject it.That's OK.But if you're using technical arguments like "that's impossible", try to read a reply, then.
P.S. when talking about security, I can understand why you want to keep aMule secure.But er, it is up to me to decide which level of security I'm want to have in my system as a whole.I see no major security problem for me if some program starts from root but then drops the rights quickly after doing priveledged things since hackers will obtain user rights, not a root just in case.And surely default setup should be secure.So, at very most, normal user should get a warning that raw socket creation has failed and feature should be disabled if user starts aMule as restricted user.Actually no security problems here except for those who launched it as root and even then, once root rights dropped quickly, there is no security problems.
P.P.S. Sorry, but you're looking a bit like a M$.These nasty morons are always deciding what is better for their users without providing any power to override their fu**ing decisions and without actually learning any users opinitions.That's why almost everyone hates M$.I'm really hope you're will not follow The One Microsoft Way.
-
I knew that some linux system required privileged access to run "ping" and firewall could sometimes prevent ping from functioning properly.
Not some, all that are not modified by the user, and this are changes the most people can't do, and the ones that can know why they aren't doing it.
But what I don't know is what is the situation of the majority linux users of amule. Based on distrowatch, the most popular distros nowadays are Ubuntu, OpenSuSe and Fedora. In Ubuntu, ping doesn't require root privileges.
It requires root privileges. As Kry stated in an early state if this thread, the binary is SetUID root, that's the reason why people think "I can ping as user".
I see ping based bandwidth control as an good options for amule users. As long as it is an option, it should be able to let users decide for themselves whether they want to enable it or not.
If this is an option, you have some alternative ways to implement that.
1. Call the ping binary you have installed. You would have another dependency and have to have an option to choose where it resides. Not good, but for me the way I hate less than the others.
2. Implement the pinging directly into aMule. To get it work, you have again two options:
2.1 Call aMule as root
2.1.1 Do some xhost or magic-cookie voodoo to get it in your X display and explain "joe average" how to do so.
2.1.2 Run X as root - No Comment
2.2 Make aMule binary SetUID root - Not Really, or?
P.S. I do as lame_azz told me. I read his post as "Ignore me, my setup is the most common out there and you're a fool", go back to Windows, it's lame too.
-
jc@jc-desktop:~$ ls -l /bin/ping
-rwsr-xr-x 1 root root 30848 2007-03-05 12:25 /bin/ping
If you didn't want to proove what Kry stated, then you either have no clue about the rights on unix, or you missed to modify this line. In first case: You see the s on the place of the execution bit of the owner? That means, that the programm, regardless who calls it, is run with the rights of the owner.
-
Please be polite and do not insult anyone. (or do it at least in an intelligent=hidden fashion)
Else today will be my monthly troll day.
Okay, I'll try.But as a moderator you have to keep others doing the same.Let's admit I'm actually do not attacking anyone first - I'm just defending from unfair attacks at very most.
OK, let's start over again with the ping thingy:
aMule is a multi-platform program. You can NOT rely on the availability of a ping executable, but you have to use your own implementation.
I'm not as stupid as you may think >:( and aware of it for sure.
Hence, it doesn't matter what fancy things your Linux system can do as long as e.g. Windows cannot do this.
Windows surely can ping.Some time ago I even tested few eMule mods implementing pinging feature.It works.Windows can do this.And I liked how it works.So I offered this for aMule as well.
In contrast to windows, on Unix systems the first 1024 ports are reserved to root and cannot be easily used by normal users.
For sure.But look, I have lighttpd on port 80 and 3proxy on another low port on my Linux machine.They are launched by root but later running as two different and very restricted users.But still listening on priveleged ports.So it is possible and works - they just do setuid and setgid after priveleged port was opened and then continue as a new, very restricted user.And well, they both can run on Windows as well, of course without executing this trick which is not needed in Windows ;).Once under Linux I setted up both daemons by hands I got some view of Linux security.It is waste of time to explain me Linux security basics - I learned it already.As well as some IPtables thingies, etc.
Short explanation of *nix terms: "setuid root" - the binary will be executed with the rights of the owner of the binary - root owns ping, thus ping has the rights of root.
I do know this.I just was a bit lame and missed the fact ping binary is suid so I wrote wrong statement (sic!).After first Kry post I re-checked it and agreed I was somewhat lame.This is not a fair reason to beat me for a whole 2 days imho and not a reason to think I'm an idiot or totally lame.
Now there are solutions (like e.g. Apache IIRC) who start as root to reserve the ports and later drop rights, but this is not possible for aMule as you would need ping rights the whole time.
Umm, but why can't aMule to keep allocated socket open and then drop rights withot closing the socket?It is not possible for raw sockets and they somehow different here?And well, read my previous post - there is other options anyway like UDP ping and round-trip times measures.
The only thing I can imagine is a single thread with the necessary rights, but I don't know if that's easily and securely possible.
Why we can't open socket and then drop rights?We have to close it for some reason or what?
-
OK, Guys. We're finished, aren't we?
Let's close this by creating a formal Feature Request in the bug tracker (http://bugs.amule.org/main_page.php) and stopping this discussion.
---
Edit: Further discussion please in channel #amule @ irc.freenode.org
Edit: Reopended upon request.
-
Opening the app with setuid root is not an option, as I stated before.
One of the MULTIPLE reasons for this is that the socket creation happens AFTER all the app setup. If anyone finds a vulnerability there, anything they can do or execute will be done with uid 0. that is so disastrous I cna't even start to think about it. Not to mention that I'd love to see you try and convince any distro or packager to include a setuid flagged aMule. Hah.
So, SETUID: not an option. ICMP Ping: not an option.
UDP ping is not an option either. Who are you supposed to ping for the UDP ping? You can't ping your ISP router with UDP. UDP is software-level, so no, UDP ping is not an option. I'm not including any DDoS usable feature with aMule.
So, UDP ping: not an option.
Roudtrip times: laaaaaaaaaaaaaame. The depend on the other end response, on routing, on the congestion on the network, and a million different parameters. Not an option. Not to mention they would and an infinite amount of complexity to the code, for no gain.
So, roundtrip times: not an option.
Total results: no options.
Current work: The kernel notifies aMule when there is free bandwith to send data. aMule sends it, up till the kernel says that the line is busy. Then it stops till the kernel notifies it again that there is free bandwith.
That's quite optimal imho.
-
Opening the app with setuid root is not an option, as I stated before.
One of the MULTIPLE reasons for this is that the socket creation happens AFTER all the app setup. If anyone finds a vulnerability there, anything they can do or execute will be done with uid 0.
Once all networking done after sockets created (and rights dropped) I see no huge security holes here.That's how lots of network daemons are working.At least, remote hackers will gain nothing - even if they'll manage to cause problems and execute code, aMule runs as restricted user at this point.Yes maybe there is option to craft some data (downloads?) in unfair manner so aMule will encounter problem on startup, this is quite improbable, hard to use and even if this done without root rights by remote I will be pretty unhappy with it (for example, attacker will be able to delete my downloads, use me to spread most prohibited warez\child porn, etc).As for local users, and rights escalations I'm will never allow any untrusted user to use P2P app on my computers.What if user will download and spread child porn or very prohibited warez?Then my ass will be kicked because it is my computer.What a funny method to get jailed instead of someone else.That's where real security comes in play - P2P app launched by untrusted user on your computer is a major security issue on it's own.Maybe other security considerations here?Let me know, I'm really want to see my faults - it is always useful to learn.
that is so disastrous I cna't even start to think about it. Not to mention that I'd love to see you try and convince any distro or packager to include a setuid flagged aMule. Hah.
You do not have to do it as default setup, nooo! :o.It is up to user to deal with this issue if he wants to use such feature.Features like this are not intended for totally dumb users.And those who know what he want to acheive will be able to resolve this problem on its own.You just to display proper message to log and add warning near feature configuration :)
UDP ping is not an option either. Who are you supposed to ping for the UDP ping? You can't ping your ISP router with UDP. UDP is software-level, so no, UDP ping is not an option.
Hmm.Do you know what happens when you're sending UDP packet to closed port according to standards?Yes, you will get ICMP reply - "connection attempt refused".And at least usual *nix socket should return an error (ECONNREFUSED afaik) due to this fact when things done properly.You definitely can measure time between packet was send and you got socket error.Voila.You got some sort of tool to measure ping times.Almost any host will reply, except those who is firewalled this port and firewall just drops packet instead of rejecting.And well, this works.You probably use this sometimes.FYI, that's how *nix traceroute works, IANA assigned UDP port is 33434 to use for this purposes (it is expected it should not be used by apps!).Windoze traceroute uses ICMP instead of UDP though.Both methods are working anyway.
I'm not including any DDoS usable feature with aMule.
Argh, instead of posting such things please, take a look on how UDP ping is implemented in the mods.It is actually some sort of adapted traceroute and you're choosing "windows-like" ICMP pinging vs "*nix-like" UDP pinging.There is no central point to ping, so nobody will be ddosed except some closest router(s) which will have to pass all your traffic anyway as their day-to-day job so it is hardly can be called a DDoS.For example in MorphXT these files named Pinger.cpp and Pinger.h, there is some windows-specific crap but you can get rid of it.And well, it is good idea to keep this feature switched off by default.Extra overhead suxx anyway so this should be only enabled someone only if he really needs to.Some channels do not have troubles with high ping when saturated -- no need to send extra data without a reason.
Note:actually things a bit more complex than I explained, take a look on mentioned sources.You may like search through source with "SpeedSense" phrase.
So, UDP ping: not an option.
Since UDP pinging requires nothing special from remote hosts and actually nobody is ddosed, maybe you can take a closer look on it?
Roudtrip times: laaaaaaaaaaaaaame. The depend on the other end response, on routing, on the congestion on the network, and a million different parameters. Not an option. Not to mention they would and an infinite amount of complexity to the code, for no gain.
Yes, it does not works very well (only when you have enough peers and still may be inaccurate and still a bit slow with bandwith control reaction speed).But better than no bandwith management at all.About infinite amount...if modders did implemented it, it is surely not infinite.
So, roundtrip times: not an option.
It is an option but worse than "real" ping.And this is increadible technique since no any extra data is being sent.
Total results: no options.
Hey, maybe take a look on option closer before making such conclusions?Except case when you're not willing to implement it for non-technical reasons.Of course you do not must to do anything users asking for.But you do not have to argue this by technical impossibility when there is such possibility and bunch of eMule mods implements these "impossible" techniques.
Current work: The kernel notifies aMule when there is free bandwith to send data. aMule sends it, up till the kernel says that the line is busy. Then it stops till the kernel notifies it again that there is free bandwith.
When there is more than one machine, kernel has no idea how much traffic goes from other machines.This leads to complete channel saturation.Ping getting pretty high.Web browsing getting slower than on dial-up since you have to send HTTP GET requests first and only then will have a responce and once round-trip time is big (since upload channel is saturated) round-trip time is big.Using traffic shaper helps a bit but as I mentioned, shaper works quite poorly with 256Kbit upload channel.
That's quite optimal imho.
As for me, it looks like completely unoptimal for my channel when co-operating with other software and there is no real options to tweak this behavior today.Setting speeds lower before you're about to browse web by hands definitely suxx.Especially if more than one user in the home are using internet.It is pain in the ass to bother someone "please, reduce your aMule bandwith!I'm wanna to browse web!I need upload file!".
-
... you just refuse to see what I type.
There is no point in explaining you things, because you see them your way, period.
Let me add that your point was that users without knowledge should be able to do this, yet you acknowledge that setuid can't be enabled by default, and that UDP ping can't be enabled by default. so no advantage for common users. For you, maybe, but then again, advanced users should know how to trafic shape their network.
Is not that I don't want to implement it, is that there is no point on implementing it. And you fall on inaccuracies and wrong statements, and defend the mods for doing what they do. Well know what, there is a reason mods do some things... and official eMule doesn't. They are 99% good reasons, and 1% lack of time.
-
Thank u Vollstrecker, I eventually understand what I have misunderstood. I see it no harm to call the ping binary inside amule while they are talking about implementing ping inside amule.
Pardon me for mistaking Kry's argument. I am convinced that Kry has a good reason to decline the request to implement ping inside amule.
1. Call the ping binary you have installed. You would have another dependency and have to have an option to choose where it resides. Not good, but for me the way I hate less than the others.
-
... you just refuse to see what I type.
No, I'm not.Maybe I just read some parts not very carefully at very most.But you doing exactly same, isn't it?
There is no point in explaining you things, because you see them your way, period.
As for me, please sorry, but it looks like you simply fail to provide any strong technical reasons to prove that implementation is not worth and that there is any real technical reasons against it.Instead, you're reverting to hardcoded "you are an idiot" position - kinda standard people behavior when there is no real technical arguments left.I can't understand this.
As for me, after some hours of googling, learning a dozen of eMule and unix sockets sources, getting idea what was implemented in eMule pinger, RTFMing, etc I can say that it looks like there is an option to implement what eMule calls "UDP ping", for example, without any major headaches.This not requires root at all, you have just to create usual UDP socket, send packet to non existing port, get reject and measure time between packet send and error returned.Surely impossible.But implemented in mods... er, wait!What? Pinger is also implemented in aMule 0.47c itself.What a funny discovery ;)
So, excuse but it looks like you just already decided for whatever reasons "it will not be implemented" and trying to use any reason to prove it.This seems to fail though, so you're sticking to "you're an idiot" conversation style without even bothering yourself to prove your words.
Let me add that your point was that users without knowledge should be able to do this,
Prove your words please, instead of just personal attacking me.Where I did mentioned this point?At very most you misunderstood something since English is not my native language so I maybe constructed sentence in poor manner.Can you quote sentence where I asked this?
As for me, I'm thinking ping should be used only somewhat skilled users who at least has idea what is is and how this will work.This required, since you have to set up ping tolerance times according to channel capabilities.
yet you acknowledge that setuid can't be enabled by default, and that UDP ping can't be enabled by default.
Yes, launching as root by default is BAD idea since this only required for some users and potentially a bit less safe.And pinging everything by default is bad idea as well since not each channel needs this and this adds some (small but still existing) overhead.
If you think that I made statement which contradicts to these words, you have to prove it.Please, give me a quote where I insisted you should run aMule as root BY DEFAULT or where I insisted that ping should be on BY DEFAULT.I gust admitted it is a good idea to have these options.Everything else is on your own, I did not told these options should be DEFAULT ones.
so no advantage for common users. For you, maybe, but then again, advanced users should know how to trafic shape their network.
Well, then, maybe you will be kind enough to tell why official eMule 0.47c is implementing these techniques?Or you will just stick to "you're an idiot" tactic again to skip commenting on this?
Is not that I don't want to implement it,
Are you sure?Really?As for me, it looks like you're just trying to find technical reasons for a 2 days.And when this fails (since I'm being an asshole and offering things which are definitely possible to implement from technical side) you're sticking to "you're an idiot" argument due to lack of another arguments.This isn't funny.
is that there is no point on implementing it.
Argh, come on, tell us, why official eMule did implemented this feature then.Yes, I was forced to grab eMule 0.47c source, take a look and yes, there is such feature in Extended options.But for Kry "there is no point" to implement it.I'm asking "why"?And getting answer "because you're an idiot".I'm like such discussions, yep ;D
And you fall on inaccuracies and wrong statements, and defend the mods for doing what they do.
If we are about to talk about accurate statements, then come on, grab official eMule 0.47c sources (and if you have Windoze box, binary as well) and take a look on them.There is these pinging options, they once were adopted from some mod.Now these features are official so asking to port them is at least reasonable.Now, you can't say any longer that I'm asking to tweaks intended just for my channel only, I guess.So, what about inaccurate and wrong statements?Are your statements 100% accurate, correct, etc so you're beating me whole 2 days like a hell?Or you're attacking first, beating for 2 days and only then evaluating if you're really right with these actions?
Well know what, there is a reason mods do some things...
For sure.They're experimenting.And sometimes manage to make things better.If improvement is really worth, it sometimes implemented in "mainline" official eMule.
and official eMule doesn't.
But it does!And please, do not tell "you're an idiot" once more.I'm already aware of your opinition about my lame ass - no need to repeat this statement (you can try to prove your statement ... if you can :P).
They are 99% good reasons, and 1% lack of time.
But features I'm talking about is not a case.They were backported to official eMule.Just grab a source and look yourself (Pinger.cpp and Pinger.h is a goot point to start).Then, we can talk about accurate statements a bit more, if you wish. ;D
-
... look
I never called you an idiot.
Yet you say I do.
So I will do it now.
You're an idiot.
You're a fucking idiot. A fucking deaf idiot.
If you're going to use UDP ping, WHICH HOST ARE YOU PLANNING TO PING?
WILL YOU RESPOND TO THAT?
FUCKING IDIOT?
Maybe caps are more your style.
-
I never called you an idiot.
Not important, duh.
Yet you say I do.
You not directly did this, but well, overall conversation style from your side was intended to show me exactly this phrase, isn't it? ;)
You're a fucking idiot. A fucking deaf idiot.
Why bother yourself telling me your opinition about me again and again?I'm already aware of it for a while thanks to your conversation style.
If you're going to use UDP ping, WHICH HOST ARE YOU PLANNING TO PING?
Read the source, Luke ;D.You will not read my answer on this anyway so typing it seems to be waste of time.
P.S. you skipped all "uncomfortable" questions.So, discussion is getting boring.I'm probably about to stop bothering here since discussions around "idiot" word isn't damn interesting for me anyway.
-
*SIGH*
The only one avoiding a question is you.
And it's a good damn question, at that.
So answer it.
(P.S: The eMule implementation uses ICMP. Never think I don't know what I'm talking about. We can't use ICMP as stated above, like it or not. That's why I ask questions about *UDP* which is NOT on eMule.)
(P.P.S: Idiot)
-
Damn you, guys...I'm not gonna close right now, I'll let you answer this last question before I ruin your fun.
The question: Whom to ping with UDP?
My answer (not having a real clue about network programming): The ISP.
Edit: Removed poll.
-
wuischke: What IP has your ISP? And how should aMule find out this adress?
-
wuischke: What IP has your ISP? And how should aMule find out this adress?
Yeah. "The ISP" is not an answer. Which *IP* should you ping?
-
What IP has your ISP?
My ISP's IP: 217.0.65.118 (one of the German Telekom routers)
And how should aMule find out this adress?
I found it out by using traceroute, which in return requires root permissions. (I don't know about another way.)
To cut it short: As far as I'm aware there's no way to *automatically* find out about this without big changes.
It is possible to implement UDP ping with manual entered IPs, which in return leads to the risk of misuse.
Another possibility would be pinging connected clients, but this is only usable for large numbers of clients - if I have only 3 connected clients I would ping them a lot more than intended. Hence when looking for an host to ping the ISP is imho the only good option.
-
Another possibility would be pinging connected clients,
No. Don't even think about it.
Hence when looking for an host to ping the ISP is imho the only good option.
And we can't find that IP programatically, we can't ICMP. so?
-
So nothing. It will not be implemented, everyone gets why and everybody is happy - or not.
I was not really making a practical point, rather explaining why the ISP is imho the only option - but still not possible.
---
Dispute seems to be settled - I can leave the thread opened.
-
*SIGH*
The only one avoiding a question is you.
Really?Are you sure?Well, you just proved once again you're do not read my messages.
And it's a good damn question, at that.
Which one?About idiots?Nope, I will not answer about idiots, it's too boring.About pings?I'm already answered it several times.Try to read my messages.This helps.
So answer it.
I'm already wasted lots of my time on you with almost zero result (argh, I learned that I'm idiot though, still not a bad discovery).And I'm still can't get idea, if you're kidding or just have absolutely no wish to implement this feature so absolutely refusing to read my messages and try to think how this can be implemented.And of course it is so hard to find example of any UDP-based *nix tracerouter in the google.
(P.S: The eMule implementation uses ICMP. Never think I don't know what I'm talking about. We can't use ICMP as stated above, like it or not. That's why I ask questions about *UDP* which is NOT on eMule.)
Argh, maybe finally you will take a look on Pinger.cpp (and other parts of this traceroute+ping derivative) a bit closer instead of just beating me, yep?Really this pinger (actually, all this rather ressembles well known tool, traceroute, so it is a bit more than pinger) is able to ping both ICMP and UDP.Looks like eMule itself has no UI option to choose ICMP vs UDP to use (or I was not able to fnid it).However, in sources, choice is here and at least some mods allowing to choose UDP ping instead of ICMP explicitly.Once eMule uses pretty same pinger source, UDP pinger code is here.I can see it somehow depends on Windows-specific crap to proceed ICMP replies even for UDP pings.But if you will take a few moments to google instead of beating me, you will find how to do the same for *nix sockets.Without dealing with ICMP sockets at all - just by getting UDP socket error ECONNREFUSED.See http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-5.html (5.4 How can I read ICMP errors from "connected" UDP sockets?).Just one of the first references in google; almost any *nix network programming FAQs has the same entry.If you're so inclined on "what IP to ping", come on, take a look on eMule sources as well.There is answer to your question.Idiot should not learn guru how to program a traceroute part of this code but well, I'm even said where to get the answer.
(P.P.S: Idiot)
Well, as we Russians saying, "idiots are lucky".Seems to be true :o.Once you have called me an idiot, my ISP has been pressed by competitors too much, so it just increased UP and DOWN speeds twice for free (wow!) and implemented some sort of QoS on it's side as well.Amazing.Please keep on calling me idiot, I'm really like how this old russian phrase works ;D.So, today I'm even unable to saturate my channel to get pings high, even with shaper turned off on my router.Now, I'm personally do not need this feature anymore.However, I can admit it is still may be usable for someone else if implemented - as you maybe noticed, this feature in official eMule so there is good reasons for this.
P.S.: Only one thing that I failed to understand after all: why an idiot must learn hardcore gurus how to perform UDP pings and how to obtain closest routers to ping 'em?I'm really not an expert in network programming (just have some protocols knowledge, nothing more).So this fact feels pretty strange for me.Where to this world going if an idiot should learn gurus how to program ping\traceroute crap which is very old thingies known to every IT-inclined schoolchildren?
-
You don't ahve to teach us anything (at least not me). There are several things you don't understand, starting from the fact that I colaborate with eMule developers, so, please, dont' tell me to read sources. It's amusing.
Taht said, we're only trying to show you the MISTAKES you have. We already know the answers, you're the one asking for explanations.
-
You don't ahve to teach us anything (at least not me). There are several things you don't understand, starting from the fact that I colaborate with eMule developers, so, please, dont' tell me to read sources. It's amusing.
IIRC, this feature was not coded by eMule developers at all, this one was created by some modder(s).Official eMule dev's just used it at some point as well (let's admit in a pretty strange manner: UDP pinger is still here as in original source, but I see no option in UI to use it while mods do have option to choose ICMP vs UDP).
Taht said, we're only trying to show you
...that I'm an idiot.Okay, let's assume I am.It is even funny to be an idiot, they're lucky.Something else? ;D
the MISTAKES you have.
Umm, as for me, all looks in another light: I'm trying to find the ways how feature can be implemented, taking *nix vs windows systems differences into account.You're beating me and trying to prove I'm an idiot.Without even bothering yourself to prove it.Or, at very best, saying some technical things and then, when I see flaw here and have something to argue against your arguments, you're sticking to "you're an idiot" tactics.Great, duh.
We already know the answers, you're the one asking for explanations
...and your answer always sounds like "you're an idiot, we do know better" without any actual proof of this point of view.Also I just wonder: you can't create "connected" UDP socket?Or you can't get idea how UDP traceroute works? ::) (well, to be exact, traceroute's derivative used in eMule but no big difference: overall algo idea is quite similar).
-
Are you done?
I want to close the door and turn off the lights...
(Tomorrow morning I will.)
-
You know that you're doing something wrong when more than 50% of what you say have exactly no relation to the topic.
- closed -