 The socket programming exercise which is assigned to you for today is a very simple file transfer protocol. File transfer protocol you might have used, FTP, of course you must have studied about it in the lectures. We are going to write a very simple client server program. The client is going to make a TCP connection. The client originates the TCP connection. The server is listening for incoming TCP connections. So, after the TCP connection is made, of course TCP is a two-way connection. Data can be exchanged in both directions after TCP connection establishment. The client is going to send a file name to the server and the server in its current directory it is going to look for this file and return the file contents. After this, the connection is closed. This is it. This is a very simple file transfer protocol that we are going to implement today. And if the file does not exist at the server side, the server is going to close the connection immediately. To make the process smoother, I have given a code template. Let me show you the code template. There is a file called ftbserver.c and there is a file called ftbclient.c. Template of the code is given and the important parts are missing which are the socket programming related calls. So, those are the blanks you see on the screen. You have to fill those blanks based on your understanding of socket programming, how to make a TCP connection, from the connection origination side, connection accepting side, connection accepting side is the server, connection origination side is the client. So, both parts you have to code up the template for which is given. Now, to make this process smooth, further smooth for those who are attempting this sort of a thing for the first time, I have given checkpoints. So, you see here checkpoint 1a, checkpoint 1b. In the main program, there is checkpoint 1. So, these checkpoints have the obvious meaning. If you have filled blanks until one particular checkpoint, comment out the rest of the code and test it. So, this will enable you to proceed in steps so that the other option is you fill in all the blanks and you do not know where it is failing. So, instead of doing that, you can check in steps. One thing to keep in mind is that the checkpoint numbers are synchronized in the client and server code. What that means is, yeah, if you want to check until checkpoint 1 in particular code, you have to have finished the code until checkpoint 1 in the other side of the code also, because it is a communication protocol, both are talking with each other. So, you have to do that. A couple of checkpoints are missing, sequence numbers are missing in the client code. Do not worry about that. You will understand as to what needs to be done. A couple of sequence numbers are missing, that is because some steps, some more steps are necessary in the server rather than at the client. So, that is why some sequence numbers are missing in the client, okay. So, this is the exercise. A few more things I have to tell. Each of you will be testing it in the local machine, okay. So, at the client, you will have to specify what is the IP address to connect to for the server. So, you have to give that local host IP address, which is 127.0.0.1, okay. That is one point to keep in mind. The other one is the port number, which is to be used for the connection at the server side is given as an argument for the server as well as for the client. This port number has to be greater than 1024 because the numbers below 1024 are reserved for super user. Even above 1024, some ports may be busy by processes which are already listening on those ports. If you get a bind failed message, this could be one of the possible reasons. There is actually another reason also why bind could fail and this is because of a previous test case. So, suppose you tested with, let's say, port 5000 client and server and you close the programs and you want to test it again. When you restart the server, it may give you a bind failed error on port 5000 if you try to run it. And the reason for this is that TCP enters this time wait state on one of the sides, okay. So this, you can look up the slides to see the details of this if you want to understand why exactly this is happening. But this can happen. This will happen when you are testing it and restarting the same program. It will say bind fail for the port which you just previously used and terminated the process for doing another test case. In such a case, you can either wait until the time wait state goes away, which is two minutes, or give a different port number, okay. So you can use 50001, 50002 like that, okay. Once you have tested it out, I will also, I mean, this is part of the exercise. I will also suggest that you can pair up with someone else and test your client code with the other person's server code and vice versa, okay. Another interesting which you can do, in thing which you can do is the file which you are transferring, you can transfer the executable itself, so transfer the executable itself and use that executable to run another test case, okay. So that's it with respect to the socket, okay. Three things I will clarify, as Kamesh had just said. One is use of this makefile, actually let me show you the makefile on screen. So makefile is a, for those of you who have not used the makefile earlier, it's a convenient way of compiling, resolving dependencies. If you don't understand what I mean, don't worry about it. So to do the compilation, all you have to do is type this command make, let me show you. So it will run the necessary compilation commands automatically. So you just have to type make, okay. So the server code is written such that potentially multiple clients can connect to it, but it will support only one connection at a time. You don't have to worry about that. You can, you only need to run one client at a time, but the server will continue to work even if multiple clients try to connect to it. It will handle only one client at a time though. The third point was the directory, yeah, so, okay. So let us say you're working in a particular directory X and the file you want to transfer has to be in the same directory. Since you're testing within the same machine, the file is getting transferred from the client process to the server process, everything is in the same directory, okay. So one thing which I have done is the file name under which the client will store after getting the file is appended with a dash dl for download, okay. So that is something you can keep in mind. You can feel free to enhance the code to, you know, remove some of these restrictions, but I have kept it simple. For those of you who complete this before time, there are some more socket programming exercises which I have, one involving UDP, another involving TCP itself. That also I can share with you. So those of you who are interested, I mean, you can also solve it later on separately. Why do you prefer to see other socket programming part more easily? Because I don't want it to be easier. You will learn more things of underneath what all things happen. So for example, you have to deal with byte order in C. You don't have to deal with it in Java. It takes care of it automatically. I mean, it's just that you will learn more things if you do using C. That's the reason. Of course, I mean, scripting languages, Python has support. It may be even easier. The point is not to get some work done. The point is to learn and C is I think best because it deals with a lot of low level details.