 send you a message. You can stand over there, but before I send the message, I have the messages just in an envelope here, just so that everyone else can see what's happening. I'm going to pass you an envelope, not yet, and you're going to see on the front, there's some information, there's some information on the front, and you'll open it and there's a message inside. You'll read the message, make sense of it, and then maybe I'll send you another message. Now, the idea is very simple, our normal communications. I send a message to someone else, and we're going to do it with an envelope, but of course in communication systems we do it with a message across the communications network or across the transmission system. Now just for this simple example, when I send a message, this is what it looks like. Here's the envelope, and on the front you may not be able to see it, but when you read it you'll see that there's four pieces of information on the front. There's the source, me, I'm the source, my address, in this case the address is my name. It's abbreviated sometimes source to SRC, so you'll see SRC equals ST, but that's the same in all messages. The destination in this case is a student, I didn't predict your name so I just left student on there, and also just for fun I include a sequence number, so I've got a number of messages, sequence number keeps track of the ordering of those messages. I'll send them in order and we often use the sequence number to keep track. This is the first, the second, and third. With a sequence number in this example I'm using two bits. What's the first message going to be? Sequence number zero, zero meaning just in decimal zero. The next one will be what? Zero one, then what? One zero, the fourth message will be fifth message. With just two bits we can only have four unique values, so in fact what we do with sequence numbers when we have a limited number of bits, we go back to zero zero, we wrap around. Usually we have a limited number of bits so we just get up to the maximum then come back to zero and so on. It won't matter in our example the value so much. Just for fun also we're going to include some data, seven bits of data. You'll see that the first seven bits are these seven digits and one parity bit on the outside. Remember last week we did a parity bit. This is the even parity check. If this is the data there are two ones so I add a parity bit of one so they're an odd number of ones. So I've created this data. What's the receiver going to do? You're going to receive, you check it's to you, they're all to you. You check that it's the right sequence number, you get them in order, then you'll open up and inside there will be some data. If you can find it and you'll see that some data inside and what do you do when you get the data? What else do you check? You should check the parity bit, make sure that there's no errors. For example you receive seven bits and you count the number of ones if there's an even number of ones here. Well you expect an odd number in total. One plus two okay. Any questions before we start? What you need to do is just take it out the data, check the parity, make sure it's correct and then tell people what data you received. Now we communicate with binary. Not very interesting to send binary so the other thing you'll do is, and I've got something to help you because I can never remember, you'll convert the binary to ASCII so I'll give you an ASCII table. We want to send a meaningful message. For example you have the table in front of you, the others can see this. If you receive one zero zero, the first three bits are one zero zero, the last four bits are one with three zeros so you look up and you get a letter H and you'll tell everyone what data you received, the letter and they will keep track of the data you receive. Okay? You can help her look up, that's okay. Any questions? I'm going to send data. Think of this as our packet or frame. The data's inside the seven bits. We attached some extra information to make the protocol work correctly. Just check the parity, look up, tell us the letter. Okay? Oh they don't care, yeah the letter's enough. You can read out the number but just the letter is the main, that's the information we want, the letter because it was an English message. I would never send such a message. Okay? I'll send the first message and give you some time. The second message hurry up. What's our problem? All of my messages are being dropped. She's too slow. The receiver is too slow in this case so I was just sending the my messages at a normal speed and it takes you some time to process the data. Okay? That is, it takes time to open up the message, look at the data, check the parity bit and then do the ASCII table look up. But while you were doing that, I sent the next message. Okay? Then I sent the next one because I don't know if I'm on the other side of the link in a real communication system. I don't know how fast you are processing. Let's try again and let's make sure I get them in the right order. I'll take the first one back. We'll try again and hopefully our receiver will not drop any messages. Maybe suggest what the receiver can do to improve that performance. You ready? What are you going to do to improve? So what happened then is I sent the first message and whoa. Okay, good. So I send the message and then what do you do with it? There's only one computer, one receiver. What can you do? Cue it. Put it in some save it for later. Okay? Okay, that's a good choice. So you receive a message and put it into some memory if it's a computing device, some buffer to save it until later. How much memory have you got? How many messages can you cue until you run out of memory? What if I have, I've got in my bag another one million envelopes? What's going to happen? Your cue will fill up. A computing device has a limited cue, has a limited amount of memory to save the messages it receives. So the same problem can potentially happen. That is, yes, you save one in memory, then the next one's received, but what if they keep coming and they keep coming? Still the cue will eventually fill up and what will happen when the cue fills up? Let's say you can fit no more on the table. You'll start to drop them again. This is just the simple concept of overflow of the receiver because the sender sends too fast. How do we fix it? Assuming you have a limited amount of memory, you can only store one in your hand at a time. Your cue is your hands. How do we fix this problem? You're processing that one? Your cue is your hands. No, you're not allowed to put them on the table. You still need to tell them the data. How much data have you received? Zero. Think simpler. What can we do so that I don't send too fast that I overflow her? Any suggestions for our receiver? How can we can avoid me sending too fast for her to receive? She tells me to slow down. How about we try this? Don't cheat and read the data first. Can I have my messages back please? In the right order? The suggestion was that you tell me to slow down if I'm sending too fast. Very simple. You know how fast you can process the data. A simple way is when you're finished processing one data message, tell me I can send the next one. Okay, so she sends something back telling me to wait. I'm waiting. I'm still waiting. Okay, now I get some indicator to send the next message. I'm waiting. I want to send. I'm still waiting. Okay, we don't need to go through the rest of the data. Okay, so we have a problem. Without any control, we have a receiver and we have a sender in a situation where the sender can send faster than the receiver can process, then we'll overflow the receiver. That's a problem. As we saw at the start, when the receiver gets overflowed, the receiver starts to drop messages. We drop the messages being sent and they don't get received. So how do we fix it? To avoid overflow, tell the sender to slow down. And it's called flow control. The receiver controls the flow of data to them by telling me to slow down. And how did you tell me to slow down? What did you say? You said wait. So I sent data. You sent back some indicator saying wait. So we need some extra communications to inform me to slow down and or to inform me that I'm allowed to send the next one. And that's what we'll call flow control protocols. Okay, one more. You're going so well. That's flow control. We'll do that today. But another thing we'll cover in another lecture a little bit later. What if there's an error? That is, let me change something. Can I borrow someone's pen? I haven't got an error yet. What if, in the normal case, and I think you've predicted what the data is, so there's no need to open read, but I send the messages at a normal speed. The receiver processes reads, reads out h, and then no need to do it. You can predict the letters, can't you? Receives the next one, checks the parity. Parity's okay, yes. Next one, parity's okay. Next one, parity's okay. Say this one, the parity's wrong. What if there's an error? You detect the wrong parity bit. That is, the parity check fails. What happens? Okay. You can send back a message saying that data I received is in error, and that's what we'll use as error control. That is, there's some acknowledgement coming back, not just the data come back, but some other special message comes back saying, the data you just sent me is in error, whether it's a parity bit or some other check, but there's some error. What if, what if I sent a message and it didn't get to you? Then you receive the next one. What happens? The data was lost, but what do you do? Do you know that data was lost? You can't see that it's lost. What's on the front of your message? What's on the front of the previous message? What's the sequence number of this one? The previous message was one, one or three. The next message is zero, one or one in decimal. What's gone wrong? Zero is missing. Zero, zero is missing. So we expect to receive the messages in sequence. That's the idea of the sequence number. If you receive out of sequence, that's an indicator that a message has been lost somewhere between the transmitter and receiver, and it's an indicator of an error. As a result, when you receive one out of sequence, what will you do? Tell me that there's an error. That's what this entire topic's about. It's a little bit more detail, but we'll go through and explain how we do that more formally in communication networks. In summary, thank you for helping. Give our receiver a hand for helping. Thank you. In summary, if I send too fast, I'll overflow the receiver and we'll lose data. As a result, we use flow control. The basic approach is that the receiver controls how fast I send. It tells me to slow down or it tells me when I can send. That's flow control. Another problem is I send data and there's an error in the data. We use error detection, detect, and we can send back some message indicating there's an error. That's part of error control. And also error control, I send a message that doesn't get to the receiver. The sequence numbers can help in identifying that some data was lost. So that's also part of error control. I think you predicted the message or close to, you predicted the first five letters. So this is what, if everything was okay, this is what you would have received, the 12 different messages. What if maybe there was an error? One message was lost. There are 12 messages. One didn't get to the destination and one arrived in error. If we didn't have error control, you may have received this data. And this may be that you don't like database systems or it's, the exam was hell. So we need to make sure that data gets delivered correctly. Okay. And that's what we use error control for. We'll try and illustrate that with our description of the different protocols. Any questions before we go back to the lecture slides?