How TCPIP Works, Part 4 Demultiplexing Connections

Yesterday, we looked at the tax you pay for a typical network stack. Where does all that tax go? Well, some part of it is dedicated to actually delivering messages to you. That's kind of an essential tax to pay. Let's look at the same picture of data framing and try to identify some of the costs of delivering messages.

Starting with the Ethernet header, we're going to be looking at parts of the message that help refine the message destination. Suppose a message has just arrived on your network cable. We now need to decide how to deliver the message. This process is called demultiplexing.

1. Look at the 48-bit destination address in the Ethernet header. This tells us which of the network cards hooked up to the cable should receive the message. Notice that IP addresses are totally irrelevant at this layer even though that's probably how the message got to your network in the first place. We used ARP to figure out the address conversion so that the message will go to the right machine.
2. Look at the frame type in the Ethernet header. This tells us whether the message is IP, ARP, RARP, or some other low-level protocol. ARP and RARP messages are going to be handled by the network driver and not your application. You will only see the IP messages coming up to you. Assume that we see a message using IP.
3. Look at the protocol in the IP header. This tells us whether the message is ICMP, IGMP, TCP, UDP, or some other mid-level protocol. Depending on the framework that you're using, you might see none or all of these protocols in your application. When using WCF, you're very rarely going to be directly dealing with this protocol layer. Assume that we see a message using TCP.
4. Look at the destination port number in the TCP header. This tells us which socket to send the message to that some application will be listening on. Some scenarios use the destination IP address or information about the message source to do additional processing. A firewall that doesn't inspect the contents of messages is probably filtering at this level.
5. Look inside the message to perform high-level protocol filtering. For HTTP, the server might demultiplex based on the URL to handle virtual hosts using the domain and path. For SOAP, the server might demultiplex based on the To address or some other header. There is a lot of flexibility at this level because more processor power is generally available to inspect messages.
6. Eventually, a message arrives at your application from across the Internet despite the fact that you didn't have to program any logic to make that happen.

We're at the end of the TCP/IP series, but this information is going to continue to show up in the future. A couple of the posts in the next few weeks will be dedicated to talking about taking WCF through NATs and firewalls. You can't really understand how that happens unless you understand the lower-level protocols. Most firewalls are at a level below WCF.

Next time: How Network Address Translation (NAT) Works