Auto get external IP
Moderator: Moderators
Auto get external IP
Is there a possibility to impelment the MOGlo function which automaticly gets the external IP. If this was implemented then I would not need to use NO-IP.com software..... I would also be great if it could detect the IP every 5 min... cos sometimes my crappy inet gets disconnected and I get a new IP when I reconnect....
The problem is that to get the external IP via normal software methods, you will usually have to find a remote server that is willingly allowing people to do something that can easily become a flood of too many requests too quickly as more and more do it. At least, I don't know of any other way that software can get this. Perhaps it could use the same resources that those dynamic IP programs use for things like the no-ip.com. It seems to me that probably if this kind of problem were going to be looked at from a coding perspective, perhaps, instead, one should work mostly server-side instead. Find some way to allow DC++ clients to ask the hub server what their IP is when they first connect (BTW, your IP can't change while you are connected without disconnecting you, so you only have to check once.) I would guess it would be best if it were some sort of command that the software would allow to only be issued once per IP per connection and there would probably need to be a short delay of maybe 30 seconds or so before the request was automatically sent to the server by the client. These restrictions would prevent flood attacks as well as possible, but I do realize it would increase the total bandwidth of the hub per user by some slight amount, so it may be a problem.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
Well, it wouldn't exactly be at the same time, but, if DC++ did that, then it would mean a HUGE increase in bandwidth for that server. If DC++ were to use such a method, it would have to have a large list of servers of that type and how to use each, and it would have to choose from the list completely at random whenever you first connect to a hub and the first time you reconnect if you get disconnected from everything. Really though, definitely the best way of doing this would be to let the hubs take the extra bandwidth. That wouldn't actually be TOO bad, but it seems that some hub owners just panic at the thought of adding even one more byte per month.
ONE MORE BYTE??
My hubs with approx 1200 users, pumps out around 15GB of data everyday.
Most of it (around 70%) is queries from those frigging passive users.
So I have a good reason to panic if the clients add deprecating features, concerning bandwidth usage.
BUT as all good hubs I am running scripts that tells the users their IP when requested
-HC-
"damn where did that 2 cents go?"
My hubs with approx 1200 users, pumps out around 15GB of data everyday.
Most of it (around 70%) is queries from those frigging passive users.
So I have a good reason to panic if the clients add deprecating features, concerning bandwidth usage.
BUT as all good hubs I am running scripts that tells the users their IP when requested
-HC-
"damn where did that 2 cents go?"
The Road goes ever on and on, Down from the door where it began. Now far ahead the Road has gone,
And I must follow, if I can
And I must follow, if I can
Er, 1200 users? That's not a very good number to represent the "average" hub... Most I've seen are no more than a few hundred at best, and often even under 200. Anyway, I'm not really saying that such an idea should necessarily be used, and, perhaps even if it should maybe it should be an option that has to be enabled so that less informed people are unlikely to use it, hopefully decreasing the number of those that do. As for my comment about some hub owners freaking out about one byte being added, I wasn't necessarily referring to you in particular. There are some people who have complained almost literally about that.
Anyway, when bandwidth limits start being reached, user limits really should be set lest the hub have major lag and even perhaps instability. If such a thing were enabled, those limits could simply be lowered by a bit. And I don't think that an IP request once per connection per user would kill bandwidth too terribly. I'm no expert mind you, but since the IP is just a few tiny numbers that are only two bytes each (for a total of 8 bytes) though there would be just a bit extra for the sending and response of the command, it might only add something like 1% more bandwidth usage per user depending on how often the majority of your users are being disconnected (if you have a lot that just sit there all the time and rarely get disconnected, then the number of requests for IP would be considerably less than if you have a bunch who just turn on DC++ whenever they feel like looking for one MP3, then shut it off as soon as they are done.)
Anyway, when bandwidth limits start being reached, user limits really should be set lest the hub have major lag and even perhaps instability. If such a thing were enabled, those limits could simply be lowered by a bit. And I don't think that an IP request once per connection per user would kill bandwidth too terribly. I'm no expert mind you, but since the IP is just a few tiny numbers that are only two bytes each (for a total of 8 bytes) though there would be just a bit extra for the sending and response of the command, it might only add something like 1% more bandwidth usage per user depending on how often the majority of your users are being disconnected (if you have a lot that just sit there all the time and rarely get disconnected, then the number of requests for IP would be considerably less than if you have a bunch who just turn on DC++ whenever they feel like looking for one MP3, then shut it off as soon as they are done.)
I have tried to optimize my service to the users from day 1Nazo wrote:
Anyway, when bandwidth limits start being reached, user limits really should be set lest the hub have major lag and even perhaps instability. If such a thing were enabled, those limits could simply be lowered by a bit. And I don't think that an IP request once per connection per user would kill bandwidth too terribly.
like upgrading hardware, getting faster connection.
even splitting up my hub in to 3 computers/hubs
and tweaking my scripts for speed and performance
Have also or been trying to block out the search bots, to the benefit for the users allready connected to the hubs.
(yep they steal bandwidth and uses cpu/script cycles on the hubs)
And having that ruined by some unneeded features on a "perfectly" good client would maybe make me rethink "why the h*ll am I doing this hub thing"
Some stats generated with Gadget's Webstats script from 1 out of 3 hubs I am hosting
Code: Select all
Hub traffic 46,64 GB Uploaded / 3,96 GB Downloaded since 5/27/2003 7:43:53 PM
Script traffic 775475195 packets handled by scripts (7496.4662 per minute)
As you can see there is some major blocks of data moved on a hub.
And we don't need more junk added to that.
baah! knowledgeable people have their own means of finding their external IP....it should maybe it should be an option that has to be enabled so that less informed people are unlikely to use it, hopefully decreasing the number of those that do....
-HC-
"found my 2 cents, and I'm not letting go of it"
The Road goes ever on and on, Down from the door where it began. Now far ahead the Road has gone,
And I must follow, if I can
And I must follow, if I can
Oh, I understand hubs have a lot of bandwidth problems. Really I sometimes wonder how people can manage it on less than a T1, if not even at least a T3... I really don't believe it would add that much bandwidth though. Anyway, I'm not saying they definitely should do that, just trying to think of the best way to do it if they did.
What about copying the moglo method, but allowing people to specify there own URL.
Then users who have access to a webserver could create there own servlet / asp / php page that would return their Public IP address.
I understand that this could lead to abuse if everyone just entered the WhatsMyIp.com url but you could block this.
Cheers,
P
Then users who have access to a webserver could create there own servlet / asp / php page that would return their Public IP address.
I understand that this could lead to abuse if everyone just entered the WhatsMyIp.com url but you could block this.
Cheers,
P
There are 10 types of people in the world, those who understand binary and those who don't.
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
Surley the whole point is that people need their public IP address in order to switch from passive mode to active mode. This type of functionality could be promoted as reducing the total bandwidth needed to run a hub.HardCopy wrote:ONE MORE BYTE??
My hubs with approx 1200 users, pumps out around 15GB of data everyday.
Most of it (around 70%) is queries from those frigging passive users.
So I have a good reason to panic if the clients add deprecating features, concerning bandwidth usage.
There are 10 types of people in the world, those who understand binary and those who don't.
parsing the output would be a matter of ease. Simply use whatever numbers it returns that are in IP syntax. However, the problem still remains that the majority of users are going to just use the most well known service among them and overall bandwidth is going to increase greatly to that service. Such a sudden increase would likely mean that said service goes down and people move on to another until the services go up and down like dalnet irc servers did when I left. I still stick with my previous point that if you must use this system, then it's best to keep a large list of known services of this sort and choose one completely at random so that the number of people hitting each should be roughly evenly distributed hopefully. At least it would keep the majority from hitting a single well known service.
I still stick with my original claim that it wouldn't be that big of a badwidth hit to the hubs. They have the least to do since they already have the existing connection and protocols open, etc. All they have to do is look at the IP address of the client that sent the request. Most of the work that would be done would be primarily a tiny bit of text passing back and forth. It doesn't have to send a big complicated response to the client like "You IP address has been resolved to the numbers 145.284.271.290 and you may now automatically switch to this at your earliest convenience." All that has to happen is the client sends whatever (getip was it?) and it responds with only the ip address. No need for sending error messages or anything because you could just return an invalid ip like 0.0.0.0 and it would be obvious that it didn't work. Such a bandwidth increase truly would be minimal since it's only a matter of a small amount of text going back and forth but not only that, it would only be the clients that actually need this. I, for example, am using a dynamic dns service because I like to have some server related things running on occasion for various reasons, so I wouldn't really want to bother with this feature as I already have something resolving my address for me. The feature woudl only be necessary for the small number of users that can't figure out how to use such a service or would only need it for DC.
I still stick with my original claim that it wouldn't be that big of a badwidth hit to the hubs. They have the least to do since they already have the existing connection and protocols open, etc. All they have to do is look at the IP address of the client that sent the request. Most of the work that would be done would be primarily a tiny bit of text passing back and forth. It doesn't have to send a big complicated response to the client like "You IP address has been resolved to the numbers 145.284.271.290 and you may now automatically switch to this at your earliest convenience." All that has to happen is the client sends whatever (getip was it?) and it responds with only the ip address. No need for sending error messages or anything because you could just return an invalid ip like 0.0.0.0 and it would be obvious that it didn't work. Such a bandwidth increase truly would be minimal since it's only a matter of a small amount of text going back and forth but not only that, it would only be the clients that actually need this. I, for example, am using a dynamic dns service because I like to have some server related things running on occasion for various reasons, so I wouldn't really want to bother with this feature as I already have something resolving my address for me. The feature woudl only be necessary for the small number of users that can't figure out how to use such a service or would only need it for DC.
Hey, does passive require more bandwidth out of the hub? I didn't know this myself.
BTW, the number of bytes contained in an IP address: 8. 2 for each of the 4 seperate numbers. The number of bytes in the text $UserIP, 14. That's a total of 22 bytes. I'm sorry, but if you can't handle an extra 22 bytes per user then you need to decrease the number of users or the first person who speaks will boot the whole hub. Not only this, but it wouldn't be per user, it would only be once per connection for only the users that even have the option enabled, which wouldn't be that many.
BTW, the number of bytes contained in an IP address: 8. 2 for each of the 4 seperate numbers. The number of bytes in the text $UserIP, 14. That's a total of 22 bytes. I'm sorry, but if you can't handle an extra 22 bytes per user then you need to decrease the number of users or the first person who speaks will boot the whole hub. Not only this, but it wouldn't be per user, it would only be once per connection for only the users that even have the option enabled, which wouldn't be that many.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
the horse, it is dead.
Search results are returned though the hub for passive users, so that is a use of bandwidth.Nazo wrote:Hey, does passive require more bandwidth out of the hub? I didn't know this myself.
If you're going to try to give technical details, at least admit that the numbers take up one byte each (we're not unicode), and that there are only 3 additional bytes for the three periods. That's 7 bytes, not 8. One byte does not invalidate your analysis, but doing the math correctly sure helps.Nazo wrote:BTW, the number of bytes contained in an IP address: 8. 2 for each of the 4 seperate numbers.
Aside from that, just look at previous topics about $UserIP. Not every hub software supports this command, even though it's been in the wild for a number of months.
Get External IP source code
Hi,
Here is the feature to add to DC++:
When active connection setting is on, DC++ will connect automatically (at launch time)
to a server to request user's external public Ip address.
To prevent flooding and increasing server bandwidth,
this feature selects randomly an url from a list of ip servers.
How to integrate this feature files in DC++ project:
------------------------------------------
1) add file GetExternalIp.cpp to DcPlusPlus project/Source Files
2) add file GetExternalIp.h to DcplusPlus project/Header Files
3) in DcPlusPlus.cpp file, insert the next source code:
if(SETTING(CONNECTION_TYPE) == SettingsManager::CONNECTION_ACTIVE) {
CGetExternalIp::newInstance();
}
after the line (65):
SettingsManager::getInstance()->load();
You have to see at final:
SettingsManager::getInstance()->load();
if(SETTING(CONNECTION_TYPE) == SettingsManager::CONNECTION_ACTIVE) {
CGetExternalIp::newInstance();
}
To do:
-----
1) For complete integration of this feature, you may create a button
to "Check External IP" in GUI "Setting/General" tab
2) List of ip servers may be set in Dcplusplus.xml or add/edit/remove in a GUI
Comment:
-------
To select a fixed server, just remove/comment in file GetExternalIp.h , the line:
#define _DCPLUSPLUS_PATCH_SELECT_RANDOMLY_IPSERVER
For your pleasure, i have included comments in source files and feel free to
add new link of ip server to the ip server list.
Enjoy this new feature.
Here is the feature to add to DC++:
When active connection setting is on, DC++ will connect automatically (at launch time)
to a server to request user's external public Ip address.
To prevent flooding and increasing server bandwidth,
this feature selects randomly an url from a list of ip servers.
How to integrate this feature files in DC++ project:
------------------------------------------
1) add file GetExternalIp.cpp to DcPlusPlus project/Source Files
2) add file GetExternalIp.h to DcplusPlus project/Header Files
3) in DcPlusPlus.cpp file, insert the next source code:
if(SETTING(CONNECTION_TYPE) == SettingsManager::CONNECTION_ACTIVE) {
CGetExternalIp::newInstance();
}
after the line (65):
SettingsManager::getInstance()->load();
You have to see at final:
SettingsManager::getInstance()->load();
if(SETTING(CONNECTION_TYPE) == SettingsManager::CONNECTION_ACTIVE) {
CGetExternalIp::newInstance();
}
To do:
-----
1) For complete integration of this feature, you may create a button
to "Check External IP" in GUI "Setting/General" tab
2) List of ip servers may be set in Dcplusplus.xml or add/edit/remove in a GUI
Comment:
-------
To select a fixed server, just remove/comment in file GetExternalIp.h , the line:
#define _DCPLUSPLUS_PATCH_SELECT_RANDOMLY_IPSERVER
For your pleasure, i have included comments in source files and feel free to
add new link of ip server to the ip server list.
Enjoy this new feature.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Get External IP source code
Mr. Copperfield, you're good, because those source files are nowhere in sight!tsm2 wrote:1) add file GetExternalIp.cpp to DcPlusPlus project/Source Files
2) add file GetExternalIp.h to DcplusPlus project/Header Files
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Get External IP source code
The problem, of course, is that tsm2 was expecting to be able to attach files, as some other forum softwares allow.GargoyleMT wrote:Mr. Copperfield, you're good, because those source files are nowhere in sight!
Hi,
For source code, follow this link
https://sourceforge.net/tracker/?func=d ... p_id=40287
Hope that Jacek will integrate it in next version of DC++.
I'd ceased any copyright to him.
Bye
For source code, follow this link
https://sourceforge.net/tracker/?func=d ... p_id=40287
Hope that Jacek will integrate it in next version of DC++.
I'd ceased any copyright to him.
Bye
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
So is this feature included yet?
Otherwise, I've written a program that resolves a hostname and writes the IP to the configuration file at startup.
Download it at:
http://www.dtek.chalmers.se/~johnk/setdcip
Otherwise, I've written a program that resolves a hostname and writes the IP to the configuration file at startup.
Download it at:
http://www.dtek.chalmers.se/~johnk/setdcip
Faced with a new IP every day from BellSouth, I've gotten around this issue with an account from DynDNS.org https://www.dyndns.org/ and a small program from Palacio de Cristal http://palacio-cristal.com/ called DeeEnEs. While the "issue" is a minor one, these seems to work nicely.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Code: Select all
jonix wrote:
So is this feature included yet?
GargoyleMT wrote:
No, it's not. I'll point out the patch to Arne, and get his feedback for 0.302
Arne told me that it will be integrated in new version, but, in which one ? dunno
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
ah. good, I lost your code with my portable...tsm2 wrote:Hi,
For source code, follow this link
https://sourceforge.net/tracker/?func=d ... p_id=40287
Hope that Jacek will integrate it in next version of DC++. :D
I'd ceased any copyright to him.
Bye
And what about SNMP ?
More and more routers are including an SNMP server, so why not adding a feature requesting the Wan IP directly from the router using SNMP?
Using this it won't add more Internet traffic and wont flood any server.
Using this it won't add more Internet traffic and wont flood any server.
MozartXP wrote:
Bad idea for others brands/models of router because there is not generic SNMP-Oid for this kind of request.
Any other idea
Good idea,m8, for your model of router.More and more routers are including an SNMP server, so why not adding a feature requesting the Wan IP directly from the router using SNMP?
Using this it won't add more Internet traffic and wont flood any server.
Bad idea for others brands/models of router because there is not generic SNMP-Oid for this kind of request.
Any other idea
The user just have to fill 2 box with :
- Router LAN IP
- Routeur WAN IP SNMP MIB OID
And that's all, everyone with a SMNP compatible router won't have to bother anymore with those WAN IP issues.
I understand that not every router is compatible, but at least, it has the advantage that it will discharge a bit Internet from those Get IP requests.
- Router LAN IP
- Routeur WAN IP SNMP MIB OID
And that's all, everyone with a SMNP compatible router won't have to bother anymore with those WAN IP issues.
I understand that not every router is compatible, but at least, it has the advantage that it will discharge a bit Internet from those Get IP requests.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: And what about SNMP ?
UPNP seems to be another up-and-coming way to handle this.MozartXP wrote:More and more routers are including an SNMP server, so why not adding a feature requesting the Wan IP directly from the router using SNMP?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Posts: 19
- Joined: 2003-05-06 22:00
Ok i have a program called "kanat" which is used for Kazaa, it finds external ip and patches kazaa in memory to force it to report that ip so you can download a host load more files "like if you don't filter out "files i can't download cause of firewall"" then i get pretty much no x'd out icons. what method Does anyone know what method kanat uses... there has to be a way to get the ip internally without trashing out someone's server... Either that or im the only person who has ever used Kanat. if anything we could rip off kanat's method if we find out who made it and is willing to make a code donation... if i had time i would code something up and send it in but i don't so...
Build a Man a Fire, and he will be Warm for a day.
Set a Man on Fire, and he will be Warm for the Rest of his Life.
Set a Man on Fire, and he will be Warm for the Rest of his Life.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Great news
Great news
i have improved some code in my personal source.
where may i upload it to you ?
kinds,
tsm2
i have improved some code in my personal source.
where may i upload it to you ?
kinds,
tsm2
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Posts: 32
- Joined: 2003-12-12 14:28
- Location: FL,USA
- Contact:
Havnt been around here in a while so i dont really know the status of this topic.. but here is a suggestion wich im sure has been suggested and probably shot down.. i assume alot of people dont connect through any proxy.. so maybe have a checkbox "Not Behind Proxy" and when you connect if the server Sends "$Supports NoProxy" then if you have the option checked.. send back "NoProxy" then have the server use the Clients (RemoteHostIP) as there ip option .. and if it dosnt then use the data in the text feild. now at first this would suck because no servers support it.. but i think it would be easy to add. like i said i dunno if this has been suggested or even added already and im sory for the post if it has.
Tim-
Tim-