views:

103

answers:

5

I am working on an embedded TCP/IP4 stack and HTTP/SNMP/SMTP stuff. It functionally works but I want to make it work faster on LAN. Because of the Nagle's Algorithm and the delayed TCP-ACK, The HTTP application seems to work slow even on LAN.

As can be seen on http://en.wikipedia.org/wiki/IPv4#Private_networks , There are 3 different Private Networks with different bit-block values.

What I will do is that:

  1. I will first be sure that I am a LAN member by looking at my own IP
  2. I will look at the dst_ip and check if it belongs to the same LAN as me

Are these enough to prove that me and the other party belong to the same LAN ?

Then of course, I will use a simple hack like sending the same packet twice to speed up the communication. I already tested this and it works but it's optional right now. I want to turn it into a built-in feature.

Thanks in advance...

A: 

Those Addresses are in use in Internal Networks (Businesses and homes). they can't be use in the Public Internet.

I think it will be ok.

Baget
In fact RFC 1918 addresses can be used on the Public Internet and are in use on the Public Internet. They shouldn't be, of course, but the only thing that stops them from being used are traffic filters on every network that uses them. It seems that lots of networks don't filter the traffic and it leaks onto the Internet. See this URL for an example of some of the networks leaking this so-called Martian traffic: http://www.ris.ripe.net/historic-reports/martians/2009/01/20090101.html
Michael Dillon
@Michael Dillon: This is the first time I hear this "Martian Traffic". I think this is caused by low-quality adsl-modems. No big network admin would do such mistake, right ?
Malkocoglu
+1  A: 

As long as you're sure nobody's using VPN connections, you're probably fairly safe. A computer connected via a VPN connection, however, will (at least normally) have an IP address that's local to your network, even though their connection may have quite (or even extremely) high latency.

Jerry Coffin
Thanks for the extra info...
Malkocoglu
+2  A: 

You need to check your subnet mask to know if a destination IPv4 address is on the same network as you. Only addresses with the same prefix will share the same network for sure.

For instance, if your IP address is 10.2.3.87 and your subnet mask is /26 that means that addresses between 10.2.3.64 and 10.2.3.127 are on the same subnet as you because they will all use the same prefix 10.2.3.64. The /26 subnet mask is 255.255.255.192.

Of course, you will do all this in binary so you will not be checking to make sure the address is between a min and a max value, instead you will use the subnet mask to get the prefix of your address and the destination address, then check that they are equal.

In binary:

10.2.3.87       00001010 00000010 00000011 01010111
10.2.3.64       00001010 00000010 00000011 01000000
255.255.255.192 11111111 11111111 11111111 11000000

As you can see, the AND mask has 26 one bits (/26) and therefore the two IP addresses share the same prefix when the subnet mask is applied.

It is possible, but not common, for other subnets to reside on the same LAN broadcast domain so in odd circumstances your performance trick will not work. If you use the subnet mask to identify the closeness of the destination IP address, then you may not need to worry about RFC 1918 private addressing.

Michael Dillon
Thank you, using subnet_mask looks better...
Malkocoglu
+1  A: 

It might be more robust to detect "low latency" connections rather than "LAN connections".

Maybe your application/stack could measure latency in some way, then switch to the alternative algorithm.

pauldoo
+1  A: 

You're (probably) better off measuring latency than looking at IP addresses. Just because two IPs do not live within the same subnet does NOT mean they have high latency between them.

Just because two IPs happen to live within the same IP range does not mean taht the have low latency (consider two ethernet segments, linked by a WAN bridge across a 64 kbps line; maybe unlikely in this day and age, but I have certainly worked with networks where links like that were common).

However, checking that two IPs are within the same subnet is certainly a good approximation.

Vatine