This is the video seven of the course treat. This video is about sockets. We already saw an example using a socket in the video discussing like how variable. In this video, we'll take a deeper look to the datagram socket, is also called UDP socket and stream socket. Datagram socket use no connection. Some users get confused just because the client side API support absolute connection where the packets are all sent to the same destination but don't be confused, datagram socket do not support connection at all. Both parts exchange datagram, datagram is a packet of the information and no guarantee is given about delivering the datagram to the other application, communicating over the sockets. The server can use the same socket to receive requests from many clients because of that server often used single thread and this may lead to kind of issue we saw in the USB. _ Server _ zero example where the local variable was not correctly initialized and the program was leaking data. In some situation the server used the received function to know that client had rest to be able to return the debt up to. The stream socket, connection is needed. The server create a socket that it uses to listen and to accept connection. The client will send a connection request. When the server receive this connection request, they create a new socket. So each connection use a different socket. And because of that command server use multiple threads to unbill a request, both parties changes stream bytes, so they no longer exchange fixed size packet of information. They exchanged a stream of bytes. The receiver must be prepared to don't receive whole data at once because to to transport this data, they are broken in packets. And packets are guaranteed to be delivered but can be delivered with small time between. Then, so when the receiver called the receive function they can get part of the information only and have to come back again. The receive function you use special flight to make the receive function wait for all the data. We will now take a look to the TCP _ Server _ 0 example and also the TCP_Hacker_0 sample that we used to send a request to the server and try to to exploit some security issues. In order to be sure you don't miss anything and we'll just put it break point at the beginning of each function. So we'll execute it and look at the the ejection. Executive this, so where initialize the socket library, create the socket. The socket will be used to accept the connection. I have to bind this socket to a network adapter. In this example, I bind this, I get to all available network adapter. It will be a more secure to forget to just the network adapter used to provide the services. I called Allyson. This example is a single thread, so I will just accept one connection at time. This is why I passed the one value web to listen as a second agreement. I just get the second name and print the report. We are listening and this will be useful when we won't want to send a request to the server. The receive and process requests. We just entered it. We'll call the except function and we'll wait until someone connect to the application. So we'll have the second number here and I will be able to use that DCB hacker, give the rest of my computer and report number. We'll just check it again. Okay. And I have to pass other option to know to let know the hacker which requests in. So the first test I will do is just send a valid request to the server. The server just got the connection request and accepted. So they now have a new socket and the socket is used to communicate with one specific clients. At this time, a real server must probably use many trend and just dispatch the new creative socket, one of the workers trade or create a new worker thread just for this request processing. And now they will try to receive the request. We look into this line. We see that the the receiver is used just to receive the header. So we don't try to receive the full request now. We'll just received theater and after that, we will be able to validate data and verify if we need to try to receive more information. We call the validator function. We learn from the UDP server example so we know that we need to value data before continuing to process the request. Well I think they are here so the result code is correct. The size is larger than the protocol leader so that's correct. When we think about the validation of the eater. The size will need to be validated against the real size of data that we received from the psychic. But this will be done later because we still don't receive the complete requests. And now we know that the size of that we are expecting so we can allocate buffer for this. I will okay just do that. If we need some more data request could be just the error. In this case, we have some data coming from the client, so we allocate buffer for that. And called a receipt under received cal I want to clearly expose the use of the MSC g underscore wait how flag. This flag just escaped to the this the socket library to wait until holder requested that received. So with the tie is large enough, it will most probably be broke and many packets to be transferred on the network and the receive function will wait until how the packets have been received before returning from the receive function. No where are we received how the data we was expecting. So it's good and we can then process the request. In this case, this is a valid request that request to do nothing. So we just send back the request with the result code change inside it. If some data also have to be sam, we will household send the data back, the request is processed. We closed the socket that was open just to talk with this client and we are ready to accept and you requests. We see that the clients receive the answer to the request. We will now take a look to what happened when we send a short request. This kind of request was causing some problems to the UDP server example but I don't expect to have a leaking data but we can maybe discover some other problems. So I just removed all the breakpoint and set one just after receiving the hater because this is the place where we want to just not that. And I use the s for short requests. So the idea is validated. Yeah and I wait. Oops, I am waiting we'll just stop the server. No, no need to wait for more longer. So what happened is that, yes I receive the error later said you have a lot of data inside it. You have a lot of data associate with this request, so you have to read it and I receive it. I used the the flag to say I want to wait for all the data in case it's a very large amount of data and this is broken in many parts. And they received block just because the hacker is not something the data he was in skating in data. What just we just saw with the TCP_Server_0 example is clearly a security flaw that can lead to denial of service attack. When the using psychiatric programmer must think about possible DoS attack. Remember you cannot solve the DoS attack by himself, but he can minimize the processing the program do before detecting the false connection and dropping it and that the king of false request and ripping it. So what is very important is to timely detect bad connection and flush it just to avoid having a tread running and they're trying to process an invalid request for a long time because the strategy is then not able to process other requests and this degrad quickly the performance of the server. And what we saw, the server was using a thread and this thread was waiting for the client to send data. And if the client does not send data, this thread will wait for a very long time until the connection is dropped. If the server used to tread pool, the attacker just need to have the same number of pending requests as the number of trade in the pool and it will simply completely stop the server. The example PCP_Server_08 just had a small, very small change. This is only the three select online here and what this line do is simply to add receive time out. So with under socket, we do not receive any data for one second. The receive function will fail and the request will be cancel and the socket will be closed so the thread will be available to receive other requests and process them. So we're very very small change. Once again there's 1/4 computer a very long time, so it's clear that the client will have time to send data or after the connecting or after sending data. This is the end of this video. The next video is about network address validation.
