1

00:00:04,720 --> 00:00:06,620

You anticipate.



2

00:00:06,910 --> 00:00:07,730

Hello, everyone.



3

00:00:07,770 --> 00:00:14,500

Today we're going to call or talk about the transport layer that we covered in the last lecture, and



4

00:00:14,500 --> 00:00:20,790

actually we're going to divide it into two topics, the UDP protocol and the TCAP protocol.



5

00:00:21,010 --> 00:00:25,040

So the UDP protocol is non connection oriented.



6

00:00:25,210 --> 00:00:32,110

So, for example, if we have a machine, A, that was to send an information to Machine B, and here



7

00:00:32,110 --> 00:00:37,210

we have machine B, the flow from A to B is one directional.



8

00:00:37,630 --> 00:00:39,890

So we don't need to notify.



9

00:00:40,330 --> 00:00:45,190

There is no notification when we're sending anything to Machine B.



10

00:00:45,230 --> 00:00:50,670

OK, so a judge decides to send something to machine B and the machine B is not aware of that.



11

00:00:50,680 --> 00:00:58,000

So on its site B don't actually need to send the information to machine.



12

00:00:58,490 --> 00:01:06,760

OK, so here we don't have any confirmation and basically the UDP simply sends information to from one



13

00:01:06,760 --> 00:01:10,810

use to another without the need to have any confirmation.



14

00:01:10,840 --> 00:01:16,860

OK, so it pretty much just sends information and the chance for errors are way less.



15

00:01:16,870 --> 00:01:21,130

So the reason for that is because we use the protocol.



16

00:01:21,530 --> 00:01:26,590

You're pretty much not allowed to transmit information that is related to the sender.



17

00:01:26,720 --> 00:01:32,720

And for that reason, the recipient will not be able to know which send the data.



18

00:01:32,860 --> 00:01:37,060

The only thing that the receiver will know is their IP address.



19

00:01:37,360 --> 00:01:45,040

So if you look at the main properties of the UDP, we can say that the UDP is unreadable.



20

00:01:45,310 --> 00:01:49,710

So there is no concept of packet transmission, for example.



21

00:01:49,870 --> 00:01:57,910

So when a packet is sent, it is not possible to know whether the packet has reached its destination



22

00:01:57,910 --> 00:01:58,360

or not.



23

00:01:58,480 --> 00:02:05,080

Also, the other piece not ordered, which means that when we send messages we don't actually receive



24

00:02:05,110 --> 00:02:08,000

the first send message first and so on.



25

00:02:08,320 --> 00:02:17,830

So also the diagrams mean that the integrity of the packet delivery is done individually for each packet



26

00:02:17,830 --> 00:02:26,560

and can actually be the only way to check if a package is delivered correctly by simply checking it.



27

00:02:26,680 --> 00:02:33,700

Finally, due to the fact that the UDP doesn't require sender sort of receiver confirmation.



28

00:02:33,940 --> 00:02:40,730

This means that the application is quite lightweight compared to the other transport protocols.



29

00:02:40,870 --> 00:02:45,720

And one of the main reasons also is that the has no error recovery.



30

00:02:45,970 --> 00:02:52,840

So it is very possible that if we receive an error, that the message is simply don't send and we're



31

00:02:52,840 --> 00:02:55,510

actually not going to get the notification for that.



32

00:02:55,540 --> 00:03:01,300

On the other side, we can have that discipline protocol, which has a few advantages as compared to



33

00:03:01,300 --> 00:03:02,520

the UDP protocol.



34

00:03:02,530 --> 00:03:07,570

So when using the protocol, the connection is actually ordered.



35

00:03:07,750 --> 00:03:15,250

So if I may here, the same example with the machines, for example, something calls to be saved from



36

00:03:15,250 --> 00:03:25,160

machine A, machine B, here is B, so that they want to send data to machine B right here and there.



37

00:03:25,450 --> 00:03:35,050

So it will send data from machine A to machine B, machine B is actually getting first informed that



38

00:03:35,530 --> 00:03:45,880

the data is going to arrive to it and it actually confirms back to Machine eight that it is OK for receiving



39

00:03:45,880 --> 00:03:46,570

this data.



40

00:03:46,850 --> 00:03:48,280

OK, and after.



41

00:03:48,280 --> 00:03:56,620

Machine beeps OK then from a we actually sent the actual data machine B, so the control of this data



42

00:03:56,620 --> 00:04:04,500

is based on the mathematical equation and allows you to verify that the transmitted data is actually



43

00:04:04,510 --> 00:04:05,120

send it.



44

00:04:05,170 --> 00:04:13,420

So, for example, if there is a reason for which the method that has been set was corrupted, we can



45

00:04:13,420 --> 00:04:20,500

easily fix that by the automatic feature of the TCAP to allow the sender to send the message again upon



46

00:04:20,500 --> 00:04:23,320

error of this sending.



47

00:04:23,500 --> 00:04:30,110

And for that reason, the protocol is pretty much referred in as one of the main protocols in the transfer



48

00:04:30,110 --> 00:04:36,540

of error layer and issues with the IP in order to transmit data over the web.



49

00:04:36,580 --> 00:04:43,870

So in real life, when you actually want to say that over Internet, it first uses the IP protocol,



50

00:04:44,410 --> 00:04:51,520

it binds the IP diagrams or the units that you're going to send, and it knows in advance that the protocol



51

00:04:51,520 --> 00:04:53,240

use is going to be the dispute.



52

00:04:53,440 --> 00:05:00,460

And the reason for preferring Tsipi is that, for example, if you are sending a message of between



53

00:05:00,460 --> 00:05:02,680

two machines, they can communicate.



54

00:05:03,230 --> 00:05:10,400

And all the status of the message that is being transmitted between them, so other main properties



55

00:05:10,400 --> 00:05:17,270

of the TCAP, we can say that it is reliable and this is because of this protocol has the ability to



56

00:05:17,270 --> 00:05:23,660

make it to manage items that can be made for sending a message if, for example, a pocket is lost or



57

00:05:23,660 --> 00:05:24,770

corrupted and so on.



58

00:05:24,800 --> 00:05:29,150

Also, the message that has been sent are sent in order.



59

00:05:29,150 --> 00:05:31,610

And for that reason, this is quite ordered.



60

00:05:31,940 --> 00:05:38,360

And the final thing due to the complexity of that method, the TCAP is quite heavy weight.



61

00:05:38,660 --> 00:05:45,920

And this is pretty much due to the fact that the TCAP has the ability to verify that the connection



62

00:05:45,920 --> 00:05:50,450

can be established through the socket even before a pocket can be sent through the web.



63

00:05:50,480 --> 00:05:57,200

So if you finally compare the TCAP and the UDP, we can say that the main difference, actually the



64

00:05:57,200 --> 00:06:04,300

most major difference between the UDP and the DP is that the TCAP is ordered for connection.



65

00:06:04,310 --> 00:06:08,060

It simply sends messages and the receiver receives them.



66

00:06:08,360 --> 00:06:15,190

So the main differences between these two methods are, for example, the difference in the data transfer,



67

00:06:15,200 --> 00:06:23,510

obviously on the Tsipi is ordered while on the Euterpe is not dedicated to point to point connection.



68

00:06:24,500 --> 00:06:30,850

And there there's no guarantee that the receiver actually received the data out there.



69

00:06:30,860 --> 00:06:41,180

Hence the DCP is way more reliable because it manages to recognize the messages were sent and received



70

00:06:41,930 --> 00:06:43,850

by the receiver.



71

00:06:44,030 --> 00:06:51,330

While the European DuraSite cannot basically verify in any physical way that the message has been sent.



72

00:06:51,350 --> 00:06:59,180

Also regarding the connection, that is, the protocol actually has a real connection from one device



73

00:06:59,180 --> 00:07:05,720

to another, and they need to be connected in order to be able to sync information in both ways.



74

00:07:05,870 --> 00:07:14,630

Then the transfer method is also different because the Tsipi reads the data and because it reads data



75

00:07:14,810 --> 00:07:19,310

as a sequence and the messages are transmitted within the different segments.



76

00:07:19,670 --> 00:07:27,950

On the outside of the UDP messages are data packets which are sent individually and the integrity of



77

00:07:27,950 --> 00:07:32,330

the packets is verified only when they arrive.



78

00:07:32,460 --> 00:07:41,000

The way both protocols work is also completely different because on one side, this connection is established



79

00:07:42,170 --> 00:07:45,740

through a process of starting a variety of connections.



80

00:07:45,740 --> 00:07:52,040

And once at least one connection is being established, then the transfer of the data can start between



81

00:07:52,340 --> 00:08:00,680

both the devices, while the UDP works in a different way and the data arrives or that it could be duplicated



82

00:08:00,680 --> 00:08:02,960

or incomplete for that reason.



83

00:08:02,990 --> 00:08:05,550

This piece way more use compared to the UDP.



84

00:08:05,630 --> 00:08:13,590

So if you actually need to correct the errors of the data and to be more secure about the data, we



85

00:08:13,590 --> 00:08:20,390

were saying you will usually use the DCP protocol while you use the UDP on the applications that are



86

00:08:20,390 --> 00:08:22,300

based on very small request.



87

00:08:22,310 --> 00:08:27,830

For example, we have just a few devices that you want them to exchange them.



88

00:08:28,040 --> 00:08:31,860

Then you might consider using the UDP as it is way more lightweight.



89

00:08:31,910 --> 00:08:35,650

So this was everything else I want to share with you about this pan-European.



90

00:08:35,990 --> 00:08:39,270

I hope this picture was interesting for you and you learn something new.



91

00:08:39,590 --> 00:08:42,820

Thank you so much for watching and I'll see you in the next lecture.