LAN zone
Moderator: Moderators
LAN zone
Let's make a really simple tweak for users who use single DC++ connecting both to their LAN Hub(s), and goes for outside world mostly.
* LAN Zone
LAN zone usually can be auto. determinated by user's Subnet Mask. But sometimes there are fast WANs (LANs routed with fast links betwen them) that will require manual settings.
Limitations: limited to 1 class B Net (?)
* Enable safe and compressed transfersr for LAN zone
Usually leaving "Enable safe and compressed transfers" enabled is a good thing, but compresing fast 100/1000Mbps transfers can kill almost any CPU.
* Additional slots for LAN zone
Like Minislots, but they are reserved for files for users connecting from IPs from LAN zone.
That's all... maksimum of 3 new GUI controls, some of them are optional (additional slots can be preset, but...), and i don't think it will really be that hard to implement?
* LAN Zone
LAN zone usually can be auto. determinated by user's Subnet Mask. But sometimes there are fast WANs (LANs routed with fast links betwen them) that will require manual settings.
Limitations: limited to 1 class B Net (?)
* Enable safe and compressed transfersr for LAN zone
Usually leaving "Enable safe and compressed transfers" enabled is a good thing, but compresing fast 100/1000Mbps transfers can kill almost any CPU.
* Additional slots for LAN zone
Like Minislots, but they are reserved for files for users connecting from IPs from LAN zone.
That's all... maksimum of 3 new GUI controls, some of them are optional (additional slots can be preset, but...), and i don't think it will really be that hard to implement?
I'm a pretty lame when it comes to programming in C++ now. Probably I could do it if I spent some time on it. But it's not the point to create another DC++ mod for 1 new feature, but to put it in existing mod, or (if it's really a must) to put in DC++ itself.
I simply think (imho) there are lot's of people who would appreciate this, so it wouldn't be a bad idea to implement it in DC++.
I simply think (imho) there are lot's of people who would appreciate this, so it wouldn't be a bad idea to implement it in DC++.
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
Basicly yes you are... You can configure anything you want as a Lan IP range... 192.169.*.* is a default range as wellPothead wrote:Would classing 10.xxx.xxx.xxx and 192.168.xxx.xxx as LAN zones, and just handeling them differently work ? Also am i missing any lan ip ranges ?
<random funny comment>
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
Nope it isn't. According to RFC 1918 it is the following ranges that are reserved for private ip's:Carraya wrote:Basicly yes you are... You can configure anything you want as a Lan IP range... 192.169.*.* is a default range as wellPothead wrote:Would classing 10.xxx.xxx.xxx and 192.168.xxx.xxx as LAN zones, and just handeling them differently work ? Also am i missing any lan ip ranges ?
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
Arh my bad, but still 192.169 addys should be LAN addys...joakim_tosteberg wrote:127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
<random funny comment>
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
Never heard of that before, but I might be wrong.Carraya wrote:Arh my bad, but still 192.169 addys should be LAN addys...joakim_tosteberg wrote:127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
Hmmm I think most common are:
10.0.0.0 - 10.255.255.255
192.168.0.0 - 192.168.255.255
172.16.0.0 - 172.31.255.255
But, for example my LAN (10.104.32.0/20) is a part of bigger network (10.*.*.*) that contains few thousand users probably, and more then 1k are using our DC hub. If this would work on all it would be quite inefficient.
Although most users with small home/office LAN won't care.
IMHO - Detecting by subnet mask usually gives best results. And as a second - option to determine range by hand (hide it somewhere on advanced tab)
10.0.0.0 - 10.255.255.255
192.168.0.0 - 192.168.255.255
172.16.0.0 - 172.31.255.255
But, for example my LAN (10.104.32.0/20) is a part of bigger network (10.*.*.*) that contains few thousand users probably, and more then 1k are using our DC hub. If this would work on all it would be quite inefficient.
Although most users with small home/office LAN won't care.
IMHO - Detecting by subnet mask usually gives best results. And as a second - option to determine range by hand (hide it somewhere on advanced tab)
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
Why?Carraya wrote:Arh my bad, but still 192.169 addys should be LAN addys...joakim_tosteberg wrote:127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us