[MUSIC]. Good day viewers.
In this segment, we'll talk about the socket API, the most widely used
interface to write applications on the internet today.
Okay, so this figure is providing you with some context to remind you of where
we're at. We have applications attach to host,
which you use in the network. The application's using this interface,
network application interface to talk over the network.
and this interface is really defining how applications can use the network.
The purpose of using these APR of course, is to let apps talk to other apps.
That's what apps want to do. They just do this via the local host, and
this api should allow them to do this while hiding all of the details of what
goes on in the, in the network, here in this cloud, which might be an isp for
instance. How many routers there are and so forth
in that cloud really shouldn't matter to the applications.
They just want to talk across the network.
So, before we dive into the details, here's a motivating application, a simple
client-server set-up. So on the left here, we have a client,
which is sending this request over the network to a server.
The client is actually a, really a client app or a program running on the host, the
client host. And when I say server, I also mean the
server app that's running on this host here, which is acting as a server.
The server app will receive the request and respond with a reply.
This reply could be anything. It depends on our application.
The reply will go back to the client app that's running on the client host.
this might be a webpage, for instance. this is a very simple patent.
However, it's a very important patent, because the basis are many different
applications, which are used on the internet today.
For instance, if you just consider file transfer, essentially, the request is the
name of the file that's sent from the client to the server.
And the server app then returns the contents of the file, that's a much
longer reply. if we just consider the web browsing
case. The request that you're sending is a URL,
so you're sending the name of a particular page you would like, and then
the response from the server, the reply from the server, is the contents of that
webpage. and yet another example is simply the
simple echo program. Where the client is sending a, a message
and the server is echoing it back. This is very useful for test
functionality. Well, this is a, a key application
patent, even though it's fairly simple. Let's see how you would write it.
Okay, to write it, we need some concrete API by which the applications running on
a host can interact with the network, and that is the Socket API.
It's providing us with a fairly simple abstraction that will let us use the
network. and as I said before, sockets, that's the
API which you use for essentially all internet applications.
So this is the one we really want to look at.
Sockets were devised long ago. They were part of the, some of the early
Berkeley Unix releases around about 1983. Since then, sockets have become part of
all major operating systems, and libraries to access them are present in
all major programming languages. Now, all of the details vary a bit from
one language to the other, and one operating system to the other, but at a
high level, they're all different socket APIs, and they all look quite similar.
They're just different in a, in a few details.
Now, there all two different kinds of network services that the socket API
provides. And the one we're going to look at is
called streams. This is a byte stream.
And it allows one application to reliably send a stream of bytes to the other
application and vice versa. that's, that's all we'll really use to
make our client's server example. There is another kind of network service
that's called datagrams, where an application can unreliably send a message
to another application. We'll look at this much later in the
course, and you can ignore it for now. Okay, so here's a, a, one more, slightly
deeper view of sockets. Now, we've said, so here's the app, and
it's running on a host. Here is the socket APIs across here.
That's the API between the applications and the network.
Sockets use a data structure that are called, unsurprisingly, a socket, to let
an application attach to the network. So, there's one socket that application's
using. An application needs at least one socket,
maybe more. And here's another socket that the other
application here is using. Sockets also have numbers, what's called
a port number. This provides a form of addressing.
You can see on the left, we have port number 1 on the left socket.
The right socket is known as port number 2.
These port numbers provide a form of addressing, and that's what allows us to
multiplex multiple different applications on a single host, because we can
distinguish between them. And here finally is the API.
this table really shows you all of the main API calls that are used for sockets.
So let's see what they are. Well, the top one here, this, this socket
call is what's used to create the socket structure itself, and that helps you
create a new communication endpoint that an application can then use to access the
network. Okay, what about the rest?
Well, there is a send call. That is what an application uses a lot
more than socket structure to send information, actually to send bytes
reliably to an application elsewhere across the network.
Okay, and you won't be surprised to learn that there's also a receive call.
And this is a call which is used by the application at the other side to receive
that information that's come across the network from the previous, from the
application that's sent it. So it's probably not surprising to you
that we have a send and receive call. What's everything else?
Well all the other calls have to do with setting up and managing connections.
when we're talking about streams, they're really analigyst to a telephone call.
Before you can simply send information across the network, you need to be able
to set up a connection. Much like making a telephone call to
connect and make sure that there's someone at the other side who's waiting
to receive information. So the connect call here is used by one
side to establish a connection to another side.
These three calls are above are bind, listen, and accept.
These are calls that are used on the incoming side to get ready, and to accept
an incoming call. And finally, the last call in this table
is the close call. And that's what you do, use to release a
connection and hang up, if you like, when both sides are finished.
So let's go into a little bit more detail, and see how we would actually use
sockets. Now, I'm drawing a time sequence diagram
here. We have a vertical line for the client.
The first host on the left-hand side. Another vertical line for the server on
the right-hand side. Time runs down this page.
So let's see what happens over time. Well, actually, first thing we need is
some phase when we connect. The two different to the client to the
server, and they connect. And then the client is going to be able
to send a request. And we want the server to respond with a
reply. And after all of that, much later on, we
can close the connection. Both sides can close the connection and
we're done. So let me tidy that up a little bit.
And you can see this is the sequence of interactions that happen, and I've
numbered them in the order in which they would happen on both sides.
So, connect, request, reply, disconnect. And you can also see the the direction in
which messages are going. I've also dotted the connect and
disconnect because these are really control operations, things that we just
have to do to support the main data transfer in the more solid line.
The data transfer's what we really want the network to do.
Well, let's go into this in a little more detail by writing down the different
kinds of socket API calls, which you use to cause this to happen.
So what am I going to do? Well actually, one of the first calls I
need on both sides is the socket call. This is really to set up our socket
structures. And what will we do?
Well the client's going to connect. Whoops, okay, hopefully you can read
that. The client connects.
And to make that happen on the server side, we need to go through a sequence of
calls. We need a bind, accept, sorry sorry, a
listen, and accept, in that order. Bind is really, so when we connect, we're
going to want to connect to a certain server host on a certain port.
Bind is really establishing an address for the communication end point, and
listen and accept, then prepare the socket to accept connections from the
other side. And accept is the call which actually
results in a, a connection being made from the other side.
Once all of that's done, what are we going to do now?
Well, we're going to send our message. That will cause this request to go over,
that's what we're going to send. We'd better call receive on this side to
be able to receive it. After the request has gone across, we're
going to want to call send on the server to send back a response.
What the response is, is up to all of the code on the server.
It could do anything, it could read a file off the disc, for instance, to get
the message to send back. But we're ignoring that because we're
just focusing on the use of the network API.
On the other side, we'll need to receive call.
And then much later on, both sides can call close.
So this is the sequence. socket calls, which are used both client
and the servers cause this interaction to happen.
So let me clean this up. Here we are.
And you can see what I've done now, is I have numbered the calls in the sequence
in which they will happen. Okay, so let's go through this.
And you'll note that I've also added a star here.
Star indicates blocking calls. Where the program makes the call and the
program is then halted by the operating system until something happens, and on
the network side. And you know, the network operation
completes and then the program gets the result and can continue.
So here's the sequence of operations. On the left-hand side, we call a socket.
Okay. On the right-hand side, we call a, a
socket, and then we go through the bind, listen, and accept.
Now interestingly here, accept is labeled number four, so it looks like we accept
the connection before we make it with step five.
That's because accept is a blocking call. Accept tells the network to wait for and
accept a connection. So, it's just like telling someone maybe
to go and sit by the phone and wait for it to ring.
Connect, on the other side is going to be someone making the call, which will cause
it to ring. Eventually, when it causes it to ring,
later down here, the program on the server side will continue.
Once the server side has picked up the phone with this accept call, what would
you do, do next? Well, if you were if you'd just picked up
the phone here actually what the program is going to do is it's going to call
receive, which is another blocking call. This is really the receiving side simply
waiting to receive information. Later sometime, you'll call send.
This is after the connect has come back and we'll call sent.
that will cause this request to go over the network to receive call someone is
waiting for and will then receive it. Now they'll work out what to do and
eventually they'll go back and send it. Of course on the other side, once we
called sent, your program has sent the informations away.
It's going to be received by someone on the other side of the network sooner or
later. But without waiting for that, you can go
ahead and call receive, which now simply tells you on the other side of the
network to now stop talking and instead, listen and wait for someone on the other
end to say something. Eventually, you'll receive the message.
That's the reply we've all been hoping for.
Then you can get that and display your web page, whatever you want to do.
And after that, we can then go ahead and close.
And we'll close on both sides. So you can see here, I've shown the
sequence of calls. and and note which ones are blocking.
Because that's sort of affecting the order and the timing of the execution in
the program. Okay, so this is really using the socket.
All that remains is for me to take these two sides and divide them so that we have
separate client and server programs. And here is the client's side, as we just
go through there. And you can see the course as we go down.
We start with the socket. Now there's actually something you
haven't seen before, something called getaddrinfo.
This is really just some translation mechanism.
You might have wanted to connect to a host called www.example.com on port 80
say. This might be a, a web server.
well, the network calls, the socket calls don't take these high level addresses.
They take things like IP address numbers, network addresses.
So getaddrinfo is translating between high level names and network addresses.
So it's, it's doing some of that bookkeeping.
Now, and then we have the sequence of calls in the same order and we go down
here, and we, we really go through just all the steps that I've previously
outlined to execute the client program. Sending the reply, receiving the message,
and doing whatever we want with it. So, what about the server?
Well, the server goes through the same things.
It, it, it creates a socket. Here's another getaddrinfo to really for
the same name, or reason, to translate between names and any addresses that are
needed. Then we go through the bind, listen and
accept calls, as before. Now then we have the usual waiting for
request, sending back the reply, and eventually closing.
Often however, this portion will be in a loop.
That's because the, the client program might exist to make a single connection
and get the information back, but often a server will be a long-running process.
It will be running, it will wait for a client to connect, and it will service
that request. Then it will for the next client to send
a request and service it and so forth. So, there will often be a loop structure
in this program. And that's it.
Now we have our client and our server pack.
I want to point out if you're writing this as code, there's lots of detail that
I've omitted here both in terms of all of the parameters in a program in C or Java
or Python or anything you like. As well as all sorts of other code to
handle error conditions that could arise if everything doesn't go smoothly.
But this is the heart of the program, and you can, by using this pattern, begin
exploring your own client server programs.
So now we know something about how to write an application and use the network.