Subnets and subnet masks

One of the most complex tasks TCP/IP has to perform is to determine whether or not a given IP address exists on the same subnet. The task isn’t really that complicated once you understand how TCP/IP uses its IP address and subnet mask, here's a very basic rundown.

An IP address looks something like this: 192.168.10.52. IP addresses always contain four numbers from 0–255, separated by periods. A portion of the IP address is called the network ID and acts as a unique identifier for a particular subnet.

The rest of the IP address is called the host ID and identifies a particular computer or network device on that subnet uniquely. How can you tell which part of the IP address is which? By using the subnet mask. A subnet mask looks a lot like an IP address, with four groups of numbers: 255.255.255.0. Remember, computers are binary machines that can understand only in zeros and ones. For the subnet mask to make sense, you have to translate it and the IP address into binary.
 

TIP: You can switch the Windows Calculator into Scientific view, which enables you to convert numbers from decimal to binary.


Convert all the four groups (octets) of numbers into binary code. For example, an IP address of 192.168.10.41 and a subnet mask of 255.255.255.0 look like this in binary:


Address or Mask 1st octet 2nd octet 3rd octet 4th octet

192.168.10.41 11000000 10101000 00001010 00101001

255.255.255.0 11111111 11111111 11111111 00000000



Everyplace you see a “1” in the subnet mask corresponds to the portion of the IP address that is the network ID. Everyplace you see a “0” in the subnet mask corresponds

to the portion of the IP address that is the host ID. Here, the network ID is 192.168.10, and the host ID is 41.TCP/IP treats everything with an IP address that starts with 192.168.10 as if it were on the same subnet. Any IP address that starts with something other than 192.168.10 is treated as if it existed on another subnet. 

 
Basic TCP/IP Services

A number of the protocols in the TCP/IP suite are considered core protocols, which means they are usually present on any network that uses TCP/IP. The core protocols provide basic services that no network can do without. These services include

_ Data transmission. Is handled by more than one protocol: the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP). Computers use UDP when they need to send a small packet of data and don’t care if the remote computer actually receives the data. Computers use TCP when loads of data needs to be transmitted because TCP allows the remote computer to reply, confirming its receipt of the data.

_ Name resolution. Provided by the Domain Name System, or DNS, protocol. DNS enables people to use easy-to-remember names like www.microsoft.com and allows computers to translate those names to numeric IP addresses.

_ Windows Internet Name System (WINS). Prior versions of Windows also use WINS to convert computer names into IP addresses. Windows Server 2003 is compatible with WINS.


   “ We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths.”

― Walt Disney
 
References:
Sybex(2003): Mastering Windows Server 2003

How TCP and UDP work

Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)is a transportation protocol that is one of the core protocols of the Internet protocol suite. Both TCP and UDP work at transport layer TCP/IP model and both have very different usage.

Lets imagine, that we need to transfer certain amount of data. You may transfer only certain amount at the time (you have limitation on the packet size, which is below TCP/UDP).

In case of TCP, first you should establish connection (you may read about "3-Way handshake"). During this you agree on the "TCP Window Size" (explained  below). Then you start actual data transfer...

You transfer a packet, and then you wait for a confirmation, that the packet received. If you didn't receive confirmation within certain amount of time, you transmit the same packet again (Retransmission occured). If you agreed on certain "TCP Window Size", you may transmit multiple packets without waiting for a confirmation, and then you receive one confirmation for all these packets (not many, usually a few, just "more than one"). If you sent 3 packets, but only two confirmed, you will send that missing packet, if no confirmation was received at all, then you send all 3 packets again. But the bottom line is - each and every packet should be confirmed.

TCP has tweaked for performance over the years. ACKs are often piggy-backed with replies to messages so there is no extra packet or waiting. It can also dynamically adjust to changing network performance with features like slow start and congestion avoidance. TCP optimizes the amount of data sent per packet to avoid IP fragmentation. With UDP, if you send a message greater than 1472 bytes (for 'normal' Ethernet) the IP layer will fragment it into multiple datagrams and it will buffered and re-assembled in the receiving stack.


In case of UDP, you just blindly split your data into packets, and transfer them without any care, if they were received or not. You may do it "at the wire speed". And if you need some kind of control over the data, this should be taken care on higher layers of OSI model (for example, you should implement transfer verification at the Application Layer).

So, in theory, TCP actual performance is at least twice slower (for example, your one-way-trip time is 100ms, you sent a packet, and wait for a response), plus depends on receiver (how long it takes to prepare and send a confirmation), while UDP may send packets "as a stream" without any delay.

That said, there are many case where UDP may be a better choice. there isn't much use for retransmissions with applications like VOIP. For a simple exchange where you don't need the overhead of establishing and tearing down a connection UDP is likely the way to go, DNS being a perfect example. Note that even DNS will switch to TCP when the server sees that the reply will be lengthy due to multiple addresses and/or MX records.

If you are creating a VoIP application, there is no need constantly to check if the other end is on-line, so you can use UDP to transfer the main payload (voice) and a second TCP connection to handle connection/disconnection at a lower speed (once a second is ok).

If you are transmitting a public radio station over IP, you need only to enable your players to join one multicast channel. In the latest case, UDP is far more effective and is causing less overhead, since all the network balancing is handled by the multicast enabled routers.

In areas of video streaming and VoIP the overhead of TCP would be intolerable, so they use UDP and they work pretty well- mainly because the network infrastructure and the protocols have "matured" to the extent where reliability is largely taken for granted.

Clear as mud?