 So, we've got a basic knowledge of how to communicate across the internet. The last thing in our five-layer stack, there's the two top layers, which are the transport layer and the application layer. Both of them are about allowing applications to communicate on the internet, so sometimes we talk about them together. So, we'll talk briefly about common things for internet applications, and then we won't have much time to talk about TCP, but I'll just introduce TCP, and there's one slide on application layer protocols. Most applications used in the internet follow a client-server model. There's two applications involved in communications for it to work correctly, so when we talk about internet applications, we mean applications that communicate across the internet to achieve some task. Running Microsoft Office or Microsoft Word on your computer is not an internet application. It's a standalone application that just runs on one computer, and it doesn't need internet access to work. We mean applications that need to communicate with other applications to work correctly. Usually they have a client-server model where one of the applications is the client and the other is the server, and that's used for initiating communications. So, what normally happens is that the server application just sits there and waits. Waits for a client to initiate communications, and it's the client that starts the communications by sending a message to the server, saying, I want to communicate with you. So the server waits for clients to communicate with it. The client initiates the communications, and once there's that initial contact, then in general, data can go in either direction. Data can go from client to server or from server to client. So when we talk about they follow a client-server model, I mean that there's usually a server that's running, waiting for someone to contact it, and it's the client that initiates the communications. And that is illustrated in a number of examples. Web browsing is the one that you know best. You have a web browser, which is your client, and that contacts a web server, which is just another piece of software running on another computer, and there are different implementations of web servers. Email is another instance that not by web access email, but by a standalone email client, like Thunderbird Outlook, in companies they use usually their own email client, it sends an email to an email server. So the server sits there and listens, and it's the client that contacts the server. Even in some cases for instant messaging, you have a client running on your computer or on your phone, it contacts some server to initiate communications to maybe find out who to send the message to. Even peer-to-peer file sharing applications use a client-server model in that there's one of the applications acts as a server that sits and waits and listens, and the other application initiates the communications, that's the client. And there are many other examples. So with a client-server communications, there are some issues that we need to deal with. First, I think many of you are good programmers, or you're learning to be good programmers, but as a programmer, if you want to create a new application, sometimes you don't want to have to deal with all the details of getting the data across the internet. For example, many applications need reliable data delivery. You send an email, that email must be delivered to the server 100% correct. You download a web page, the web page transfer from the server to your client must be have no errors. You download a file, you don't want any errors. But in networks and in links, there can be errors. So instead of the application programmer having to deal with errors, remember IP does not. IP just sends datagrams. If something gets lost, then it will not retransmit. That's left to transport protocols, in particular TCP. TCP is the main transport protocol in use in the internet, and one of the core features is it provides reliability. If you're downloading a file and something goes wrong in the internet, TCP will trigger a retransmission of some of the parts of the file. And other things that transport protocols do. The idea is that an application developer doesn't have to deal with retransmissions. And you'll be pleased to know if you write an application, you don't have to write flow control or error control and understand that like you did in the assignment. The application programmer just says, send the data to TCP and let TCP do the retransmissions and flow control. So many client server applications need those same services. They are left to transport protocols. The programmer doesn't have to implement them. Someone else does. The application programmer. Consider that. With internet communications, I want to communicate between my browser running on Ubuntu Linux using Firefox to a web server running on Windows 8 on the other side of the world. Different operating systems. The applications, my browser and the web server implemented using different languages, one maybe in C, one's in Java. You still need to allow them to communicate. And to do that, people have come up with a common API. What's an API? Application something interface. Programming interface. So it's basically application programming interface. Some standard definition of how to call functions or use objects methods such that when you write an application using, let's say, C on my Linux computer and compile it, it will communicate with a Java application running on Windows somewhere. Different languages, different operating systems, but if they follow the same API, they can communicate. The name of that API is called Sockets. That's something that's important for applications but something we will not touch in this course. You may see it in other courses. How to program internet applications. The other thing that's very important is that, of course, many computers on the internet may run more than one application at the same time. You run an instant messaging client. You run a web browser, an email client. A server can be running multiple pieces of software at the same time. So we need some way to identify different applications on the same computer. We'll introduce what's called ports or port numbers do that for us. So let's briefly talk about transport protocols and ports and some of the numbering that's used. And that will finish us for this topic. Transport protocols. Transport protocols to support communications between processes, application processes. So an application runs as a software process on your computer and transport protocols allow communication of data between a process on my computer and a process on the server computer. Transport layer and application layer host to host or end to end communications. The routers are not involved. They just forward the data. There are different transport protocols but the main one that we need to be aware of is TCP, the transmission control protocol. It's very important because it provides error control, meaning if we send data it will handle retransmissions. It provides flow control in that if we send data too fast it will slow down so that we don't overflow the receiver. And related congestion control which is if we send data too fast we don't want to overflow the routers in the internet and cause congestion. So it's a very, very important part of how the internet performs today. Many applications use it because of the error control features. Instead of having to implement your own error control you just use TCPs. There are others though. One common one is UDP. It doesn't provide error control, flow control or congestion control. It pretty much does the same as IP. And there are a few other very specific ones only for very special cases, transport protocols. There's not so many. Each transport protocol is given a number. So there's an organisation called the Internet Assigned Numbers Authority, IANA, who not only allocate IP addresses but also set numbers for the transport protocols. For example, TCP is the number six, UDP is number 17. Another one you may see next semester, ICMP is number one and there are others. Protocol numbers, there's a website that lists them all. So the standard that ICMP number one, TCP number six and others routing protocols and a few others are listed here. Why is that important? It's important because when you receive data and there's multiple transport protocols on your computer, the IP software needs to know which transport protocol does this data go to. We'll see an example of that in a moment. Note that the protocol number is in the IP header. If you remember back to that picture of the IP header, there was one field called protocol. It's the number of the transport protocol. We'll go through an example of the protocol number after we introduce port numbers. We'll combine them. Another important part is we said clients initiate communications to servers. How do you know or how does the client know how to contact and identify the server? That's important. Well, in the internet, IP addresses are used to identify hosts. More specifically interfaces on hosts but generally it's one host, one interface. If I want to contact the ICT web server, what do I need to know? I tell you open your browser and go to the ICT web server. What do you need to know to do that? Know the name. I've told you ICT web server. What more specific do you need to know? Be specific. I want you to connect from your browser the address and what is the address? ICT.sit.tu.acd.th. That is a domain name. But in fact that maps to an IP address. The IP address for the ICT web server inside here is actually 10.10.6.11. You can try it later. Open your browser and type in 10.10.6.11. That's the actual IP address of the ICT web server. There's some magic for how to map the domain name ICT.sit.tu.acd.th to the IP address. But we don't have time to explain the magic. You have to sometimes believe. The IP addresses identify computers. So if I want to contact the ICT web server I need to let's say know the address is 10.10.6.11. I know it. I run the server. But I'm telling you so you know it now. But my application may use a different transport protocol. So I need to know the transport protocol in use. And the way that we know that is by a protocol number. So if the protocol number is 6 I know that the transport protocol is TCP. If it's 17 I know it's UDP. The other thing I need to know is that I may be running different applications. So we use a new number called a port or a port number to identify applications on a host. Let's use an example to explain that. Here's the example picture. I've got it somewhere. This shows two hosts. A source host and a destination host connected via a set of routers. The internet cloud here. Focusing on the top three layers. At the center we have the network layer IP. How do we identify a host on the internet? How do I identify a host on the internet? What type of address? A host on the internet is identified with an IP address. That's what we spent an hour or so covering. So for example, if I can say that, so the destination host, let's say I know the IP address is, I'll write it here, 10.10.6.11. That's the IP address of the ICT web server. What was my laptop? My laptop I think before the example was 10.10.105.80, just as an example. So I think that each host has an IP address and the IP address can uniquely identify the host on the internet. Now there's again some complexities about different types of addresses which are only used inside an organization as opposed to those used outside. But let's assume every IP address uniquely identifies a computer in the world. So if I want to communicate to the ICT web server, I need to know its IP address. I know it. It's 10.10.6.11. But inside each computer we may have different transport protocols, TCP, UDP, ICMP and others. So if I open my web browser and type in the destination address of 10.10.6.11, my source host is going to send a packet across the internet. It should go to 10.10.6.11, but I need to be more precise. I need to make sure that that packet will not just go to 10.10.6.11, but will also go to TCP and to the web server on this computer. If it's my web browser, I don't want the message to go to the instant messaging client on someone's computer. I don't want it to go to the email server or some other server on the computer. I want it to go to the web server on that computer. So we use protocol numbers to identify transport protocols and port numbers to identify servers or applications to be in general. Let's see how we do it. Transport protocols are assigned numbers. So when I'm using web browsing, we use TCP and the number for TCP is six. It's the same at every computer. Everyone who uses TCP gets the number six. If you're using UDP, it's 17, and ICMP, just for completeness, is one, but there are others. Let's say I'm using my web browser. I want to contact the web server at 10.10.6.11. My web browser uses the application protocol HTTP. HTTP actually uses TCP as the transport protocol. What happens is that I create a message inside my computer and the destination address will be what? We'll focus on the destination. When I create the message to be sent across the internet, what would the destination IP address be? If I want to send to the ICT web server, so I'm going to create an IP datagram, send it across the internet. Inside that datagram is a destination IP address. The value will be, in this example, where should I send it on the internet? 10.10.6.11, easy. Destination IP address will be 10.10.6.11. I guess we should also list the source. The source, in fact. Source IP will be mine. Destination IP will be that of the computer on the internet that we want to contact. 10.10.6.11. If we send a packet across the internet and it gets to 10.10.6.11, when the IP software inside that destination host gets the data, where does it send it to? Which transport protocol? We've just sent an IP datagram across the internet. It arrives at the network interface, the IP software gets the data. Which transport protocol does IP send the data to? YTCP. 6. But how does IP know? The 10.10.6.11 doesn't correspond to the 6 here. When IP at the destination host receives an IP datagram, I've got the data because of the destination address sends it to me, I get the data, but how do I know which transport protocol do I send that data to? That's the problem we have. We need some way to identify the data that you get goes to TCP. Or maybe, if a different application is being used, the data you get goes to UDP. So we need some way to identify which transport protocol should get the data. I will not switch back, but if you look in the IP header, there was a protocol field. It's included in the IP header by the source, protocol or protocol number. And that tells the destination which one to send to. So in fact, when my computer creates the datagram, it sets the source address to mine, the destination address to that destination host, and the protocol field inside the IP header is set to 6. In that way, when the datagram arrives here, IP knows the data needs to go to TCP because it's number 6. If the protocol field was set to 17, IP would deliver the data to UDP. So the protocol number identifies the transport protocol. So we're okay in that TCP receives the data. Where does TCP send that data to? Why does it send to the web server? No, TCP may be used by multiple applications, email server, web server, many applications use TCP, database, client, okay. So we need another address to identify when TCP gets the data, do I send it to web server? Do I send it to the instant messaging client? Do I send it to some other application? The port number is the other type of address. So think applications have a port number, and the common approach is that server applications like a web server will use a common port number, and it turns out a web server usually uses port 80, MSNP, Microsoft network protocol, this is an old picture, I can't remember the port number, I don't know it. Let's make one up, let's say it's 2300. That's just a random number I made up, not relevant. But the idea is that each application has a port number. So the transport protocol header also includes the source port, which application did it come from and the destination port? Which application is it going to? This is for example included in the TCP header. The destination port if we're trying to contact a web server will be port 80. The source port is the port number given to your web browser. What port number does your web browser use? It's usually not fixed, it's usually assigned by your operating system when you start your web browser. So it may change, so I don't know. But it's usually a large number, let's say 50,123. When I start my web browser tomorrow it could be a different port number. That's the source port. Of course when the web browser has started it will know or the operating system will know the port number. So what happens? At the source computer it creates an IP datagram, the first three fields are included in the IP header. The source IP will identify who sends it, the destination identifies which computer on the internet it needs to go to, the protocol number identifies the transport protocol on that destination computer that needs to receive it, TCP in this case. Then the port numbers identify the specific applications. In this example that's included in the TCP header. If we're using UDP in a different example it also has the source and destination port. This packet is sent across the internet, it's delivered to the IP software at 10.10.6.11 which delivers the data to TCP which knows to deliver the data to the web server because the destination port is 80. And of course the web server wants to send back a reply. The source address, the source IP tells this computer where to send the reply to. The source port tells it which application to send the reply to. The protocol number stays the same because both endpoints use the same protocol. These are five very important addresses in the internet and in fact any form of internet communications can be identified by these five combinations. Source and destination IP address think identify computers on the internet. Protocol number identifies transport protocol being used, there's only one, the same one at both endpoints. And source and destination port numbers identify the applications involved in the communications. So if you see a message in the internet with these values you know it's from a web browser to a web server or very likely because the port number 80 identifies a web server. Any questions? We'll finish at 5.30, don't worry. Port numbers. Port numbers are 16 bit values ranging from zero up to 65,000 approximately. There are some port numbers which are mainly used by servers called well-known ports. Some ones you may have seen, port 80 for HTTP, HTTBS 443, secure shell 22 and others. And there's a file or there's a standard that lists them. Registered, that should be registered, ports are used for other servers which are not so common but mainly for servers. And then the client has a port which is called a dynamic port which is assigned by the operating system usually from the range of around 50,000 upwards. You will study TCP and especially we'll see the addresses and I've said it many times in the lab next semester we'll go into the details of how TCP works and how we use this addressing information to identify what's happening in communications in the internet. Today is just a taster for what will come next semester. So TCP we will not cover and we'll go, you should look at the header format, it contains the source port and destination port. It uses flow control and error control like you just studied in the assignment. It sets up a connection before we send data, it sets up a connection which we'll study again next semester and has some complex mechanisms for data transfer. Application layer, many different protocols at the application layer. Some you've heard of that many others for specific applications you may not have used. Some of them are listed there. Applications as well as supporting the network operation, many different protocols that we need to understand over the next year or so.