From 76d0bf702eff324242a32aa5c4fbd5fb4c1995e8 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Wed, 22 Apr 2015 15:31:37 +0200 Subject: [PATCH 01/80] added alt text to wikipedia link --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 42ccabad..3ab53363 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -8,7 +8,7 @@ ## TCP vs UDP -TCP and UDP are 2 of the most used protocols to comunicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](http://en.wikipedia.org/wiki/OSI_model) TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. +TCP and UDP are 2 of the most used protocols to comunicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](http://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model") TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. ### TCP From 04e81269f0c35fa29677380db25696481c30a401 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Wed, 22 Apr 2015 15:32:22 +0200 Subject: [PATCH 02/80] wikipedia https link --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 3ab53363..2b8e54dc 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -8,7 +8,7 @@ ## TCP vs UDP -TCP and UDP are 2 of the most used protocols to comunicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](http://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model") TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. +TCP and UDP are 2 of the most used protocols to comunicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model") TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. ### TCP From 790828b7ac7fe52a70b39e48b7bebf71639d5fea Mon Sep 17 00:00:00 2001 From: tpltnt Date: Wed, 22 Apr 2015 15:37:36 +0200 Subject: [PATCH 03/80] added missing period --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 2b8e54dc..57883daf 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -8,7 +8,7 @@ ## TCP vs UDP -TCP and UDP are 2 of the most used protocols to comunicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model") TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. +TCP and UDP are 2 of the most used protocols to comunicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. ### TCP From 8c91d4d88431a571db18a622b475703eebe057bf Mon Sep 17 00:00:00 2001 From: tpltnt Date: Wed, 22 Apr 2015 15:42:25 +0200 Subject: [PATCH 04/80] split sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 57883daf..8e8141f0 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -12,7 +12,7 @@ TCP and UDP are 2 of the most used protocols to comunicate through a network. In ### TCP -**Transmission Control Protocol**, is without doubt the most used network protocol on the Internet, it is a protocol based on a connection, stream based and resistant to errors, package reordering and package lose. Let's see what all that means. +The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol based on a connection, stream based and resistant to errors, package reordering and package lose. Let's see what all that means. To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided in packages, each segment of the network might support a different package size so it might subdivide our packages into smaller packages. A package is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packages is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packages and adding some headers to them allows us to detect errors per package so we only need to resend the corrupted packages instead of the whole thing. From a347af3ad19ef7bb7e214ee25a378b447c6a9c9e Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 23 Apr 2015 16:44:39 +0200 Subject: [PATCH 05/80] proposed rephrasing with regards to TCP --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 8e8141f0..1b7776f2 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -12,7 +12,7 @@ TCP and UDP are 2 of the most used protocols to comunicate through a network. In ### TCP -The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol based on a connection, stream based and resistant to errors, package reordering and package lose. Let's see what all that means. +The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a managable connection, UDP is more geared towards streams]** and resistant to errors, package reordering and package lose. Let's see what all that means. To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided in packages, each segment of the network might support a different package size so it might subdivide our packages into smaller packages. A package is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packages is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packages and adding some headers to them allows us to detect errors per package so we only need to resend the corrupted packages instead of the whole thing. From 7e2ee9c9952a9bd9d41b56dcc39bad978d62e376 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 23 Apr 2015 16:48:20 +0200 Subject: [PATCH 06/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 1b7776f2..7055e36b 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -14,7 +14,7 @@ TCP and UDP are 2 of the most used protocols to comunicate through a network. In The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a managable connection, UDP is more geared towards streams]** and resistant to errors, package reordering and package lose. Let's see what all that means. -To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided in packages, each segment of the network might support a different package size so it might subdivide our packages into smaller packages. A package is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packages is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packages and adding some headers to them allows us to detect errors per package so we only need to resend the corrupted packages instead of the whole thing. +To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided in packages. Each segment of the network might support a different package size so it might subdivide our packages into smaller packages. A package is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packages is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packages and adding some headers to them allows us to detect errors per package so we only need to resend the corrupted packages instead of the whole thing. When we send a package from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there's several paths to arrive from one point to another and packages go through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next package could go through a different route and even arrive before than packages that were sent before. From 32f0a7c8f8c571881433cb970eef1ee2fa6830e0 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 23 Apr 2015 17:14:28 +0200 Subject: [PATCH 07/80] package -> packet, since that is the nomenclature in the computer networking domain --- chapters/network/chapter.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 7055e36b..1fb3c1f0 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -12,21 +12,21 @@ TCP and UDP are 2 of the most used protocols to comunicate through a network. In ### TCP -The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a managable connection, UDP is more geared towards streams]** and resistant to errors, package reordering and package lose. Let's see what all that means. +The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a managable connection, UDP is more geared towards streams]** and resistant to errors, packet reordering and packet lose. Let's see what all that means. -To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided in packages. Each segment of the network might support a different package size so it might subdivide our packages into smaller packages. A package is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packages is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packages and adding some headers to them allows us to detect errors per package so we only need to resend the corrupted packages instead of the whole thing. +To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided into data packets. Each segment of the network might support a different packet size so it might subdivide our packets into smaller packets. A packet is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packets is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packets and adding some headers to them allows us to detect errors per packet so we only need to resend the corrupted packets instead of the whole thing. -When we send a package from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there's several paths to arrive from one point to another and packages go through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next package could go through a different route and even arrive before than packages that were sent before. +When we send a packet from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there's several paths to arrive from one point to another and packets go through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next packet could go through a different route and even arrive before than packets that were sent before. -Another problem is that packages might get corrupted on their way to the destination computer, for example, because of electrical noise in some of the cables. +Another problem is that packets might get corrupted on their way to the destination computer, for example, because of electrical noise in some of the cables. -With all that let's say we send packages ABCD in that order, it might be that at the other end we get something like GCB: package A got corrupted and turned into G, packages B and C arrived ok but in the wrong order, and package D was totally lost. +With all that let's say we send packets ABCD in that order, it might be that at the other end we get something like GCB: packet A got corrupted and turned into G, packets B and C arrived ok but in the wrong order, and packet D was totally lost. -TCP is able to solve all of those problems. when TCP sends packages it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a CRC to each package that allows the other computer to know if that package is corrupt. +TCP is able to solve all of those problems. when TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a CRC to each packet that allows the other computer to know if that packet is corrupt. -When the destination receives a package and that package is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the package again. Whic solves the problem of corrupted and lost packages. +When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. Whic solves the problem of corrupted and lost packets. -This ACKs also allows to regulate the speed with which packages are sent so if the clienthas less bandwith than the server, the server can slow down sending packages till it arrives to the speed at which the client can receive them +This ACKs also allows to regulate the speed with which packets are sent so if the clienthas less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them As we see, using a TCP connection ensures that everything we send is received correctly on the other side. @@ -46,7 +46,7 @@ On the other side, the application using TCP, we may receive it like: "twork mess" "age" -We can't even be sure of which size those packages are going to have. There's tricks to send full messages, like adding a delimiter to them, for example openFrameworks when doing: +We can't even be sure of which size those packets are going to have. There's tricks to send full messages, like adding a delimiter to them, for example openFrameworks when doing: ```cpp tcpClient.send("Hello world!! this is an openFrameworks network message"); @@ -72,15 +72,15 @@ tcpClient.setMessageDelimiter(myDelimiter); Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect ot it. -There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has it's own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packages back to us. +There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has it's own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. -While this is really practical, it means that if we have 2 computers behind NAT routers, it's imposible to open a connection between them (in principle) . There's ways to configure a router to send any package sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP. +While this is really practical, it means that if we have 2 computers behind NAT routers, it's imposible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP. ### UDP UDP or **User Datagram Protocol**, is a non-connection datagram oriented, non error resistant protocol. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening in that machine and that port it will receive the message. -Datagram oriented means that whatever we send, that fits in the package size supported by the network, by all the subnetworks in the path from one computer to another, will arrive in one piece on the other side. In openFrameworks, if we do: +Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the subnetworks in the path from one computer to another, will arrive in one piece on the other side. In openFrameworks, if we do: ```cpp string message = "Hello world!! this is an openFrameworks network message"; @@ -89,19 +89,19 @@ udpManager.SendAll(message, message.size()); The other side will receive that message in one piece. That is, if it receives it at all. -As we've said before, UDP is not resistant to errors so the package may not arrive. It may get corrupted and there's no way to recover it. If we send several packages they may arrive in a different order then they were sent. UDP also doesn't adjust for bandwidth, so if one side is sending faster than what the other side can receive, or even if it fills the local buffers while sending, some packages will get lost. What's worse, we won't receive any advice that they got lost, nor in the sender nor in the receiver. +As we've said before, UDP is not resistant to errors so the packet may not arrive. It may get corrupted and there's no way to recover it. If we send several packets they may arrive in a different order then they were sent. UDP also doesn't adjust for bandwidth, so if one side is sending faster than what the other side can receive, or even if it fills the local buffers while sending, some packets will get lost. What's worse, we won't receive any advice that they got lost, nor in the sender nor in the receiver. -UDP might seem not useful but it has some advantages. Sometimes, we don't mind some packages being lost. For example, if we are sending a package every few frames with the state of our application we don't mind if sometimes we don't receive one of them. It's also really hard to loose a package on a local network, but if you need total reliability don't trust UDP, just use TCP. +UDP might seem not useful but it has some advantages. Sometimes, we don't mind some packets being lost. For example, if we are sending a packet every few frames with the state of our application we don't mind if sometimes we don't receive one of them. It's also really hard to loose a packet on a local network, but if you need total reliability don't trust UDP, just use TCP. Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the broadcast address we need to know the IP address of the machine from where we are sending and the subnetwork mask by doing a bit xor on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive... UDP, as we mentioned before, allows us to do NAT transversal using some clever tricks although is not something that can be done with raw UDP and requires a third party library. -A case where UDP might be preferable over TCP is in very time critical applications, you might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a package gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent so that might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packages than having to wait for them to be resnet. We are usually talking of milliseconds here so as we've said it is usually not a problem. +A case where UDP might be preferable over TCP is in very time critical applications, you might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent so that might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resnet. We are usually talking of milliseconds here so as we've said it is usually not a problem. -Another possibility is implementing part of the error recovery in TCP while using UDP, for example we might not mind loosing some packages or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement package reordering in UDP simply by using a sequence number in each messsage and reorder the packages in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message thath might arrive later needs to be processed before. +Another possibility is implementing part of the error recovery in TCP while using UDP, for example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement packet reordering in UDP simply by using a sequence number in each messsage and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message thath might arrive later needs to be processed before. -In general use TCP if you need your messages to arrive no matter what, when loosing even one package might be critical and UDP if you need some of the most advanced uses like broadcasting, multicasting, NAT transversal, or when waiting for lost packages to be resent, even a few milliseconds, might make be critical for the application while loosing some packages is ok. +In general use TCP if you need your messages to arrive no matter what, when loosing even one packet might be critical and UDP if you need some of the most advanced uses like broadcasting, multicasting, NAT transversal, or when waiting for lost packets to be resent, even a few milliseconds, might make be critical for the application while loosing some packets is ok. ## OSC From bab5f647fa1b7f0ecffeb2923224f92f8acbabf7 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 23 Apr 2015 17:20:36 +0200 Subject: [PATCH 08/80] there is -> are (plural) --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 1fb3c1f0..85a95797 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -16,7 +16,7 @@ The **Transmission Control Protocol** is without doubt the most used network pro To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided into data packets. Each segment of the network might support a different packet size so it might subdivide our packets into smaller packets. A packet is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packets is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packets and adding some headers to them allows us to detect errors per packet so we only need to resend the corrupted packets instead of the whole thing. -When we send a packet from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there's several paths to arrive from one point to another and packets go through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next packet could go through a different route and even arrive before than packets that were sent before. +When we send a packet from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there are several paths to arrive from one point to another and packets go through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next packet could go through a different route and even arrive before than packets that were sent before. Another problem is that packets might get corrupted on their way to the destination computer, for example, because of electrical noise in some of the cables. From 7c0893874f7660e68145d91d5a013ce3289e3472 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 23 Apr 2015 17:21:37 +0200 Subject: [PATCH 09/80] arrive -> go (from one point to another) --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 85a95797..773e7e92 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -16,7 +16,7 @@ The **Transmission Control Protocol** is without doubt the most used network pro To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided into data packets. Each segment of the network might support a different packet size so it might subdivide our packets into smaller packets. A packet is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packets is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packets and adding some headers to them allows us to detect errors per packet so we only need to resend the corrupted packets instead of the whole thing. -When we send a packet from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there are several paths to arrive from one point to another and packets go through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next packet could go through a different route and even arrive before than packets that were sent before. +When we send a packet from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there are several paths to go from one point to another and packets go through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next packet could go through a different route and even arrive before than packets that were sent before. Another problem is that packets might get corrupted on their way to the destination computer, for example, because of electrical noise in some of the cables. From 0d29ae7a2573c6777288c82081d8a616078368b8 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 23 Apr 2015 17:22:06 +0200 Subject: [PATCH 10/80] go -> travel (to avoid duplication) --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 773e7e92..e68305ce 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -16,7 +16,7 @@ The **Transmission Control Protocol** is without doubt the most used network pro To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided into data packets. Each segment of the network might support a different packet size so it might subdivide our packets into smaller packets. A packet is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packets is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packets and adding some headers to them allows us to detect errors per packet so we only need to resend the corrupted packets instead of the whole thing. -When we send a packet from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there are several paths to go from one point to another and packets go through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next packet could go through a different route and even arrive before than packets that were sent before. +When we send a packet from one computer to another, even with a connection based protocol like TCP, there's no way of knowing in advance which path it's going to arrive through. On the Internet there are several paths to go from one point to another and packets travel through whatever path is more optimal at the moment they are sent. But that path might no longer be the ideal path some milliseconds later, so the next packet could go through a different route and even arrive before than packets that were sent before. Another problem is that packets might get corrupted on their way to the destination computer, for example, because of electrical noise in some of the cables. From adbb048255d3bde9a7f1e5d0a5e05d4418c6a050 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 23 Apr 2015 17:24:11 +0200 Subject: [PATCH 11/80] capitalize beginning of sentence --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index e68305ce..5ef33a2b 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -22,7 +22,7 @@ Another problem is that packets might get corrupted on their way to the destinat With all that let's say we send packets ABCD in that order, it might be that at the other end we get something like GCB: packet A got corrupted and turned into G, packets B and C arrived ok but in the wrong order, and packet D was totally lost. -TCP is able to solve all of those problems. when TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a CRC to each packet that allows the other computer to know if that packet is corrupt. +TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a CRC to each packet that allows the other computer to know if that packet is corrupt. When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. Whic solves the problem of corrupted and lost packets. From 93588a491974b63ff847c0a0164a9618b08c99e0 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 23 Apr 2015 17:25:44 +0200 Subject: [PATCH 12/80] added wikipedia link to CRC --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 5ef33a2b..6a3fbc6a 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -22,7 +22,7 @@ Another problem is that packets might get corrupted on their way to the destinat With all that let's say we send packets ABCD in that order, it might be that at the other end we get something like GCB: packet A got corrupted and turned into G, packets B and C arrived ok but in the wrong order, and packet D was totally lost. -TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a CRC to each packet that allows the other computer to know if that packet is corrupt. +TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a [CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check "Wikipedia on Cyclic Cedundancy Check" to each packet that allows the other computer to know if that packet is corrupt. When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. Whic solves the problem of corrupted and lost packets. From 45fc9b0c439a0720354a0e594f594b427be74184 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:27:15 +0200 Subject: [PATCH 13/80] typo fix --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 6a3fbc6a..2934b4e9 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -22,7 +22,7 @@ Another problem is that packets might get corrupted on their way to the destinat With all that let's say we send packets ABCD in that order, it might be that at the other end we get something like GCB: packet A got corrupted and turned into G, packets B and C arrived ok but in the wrong order, and packet D was totally lost. -TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a [CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check "Wikipedia on Cyclic Cedundancy Check" to each packet that allows the other computer to know if that packet is corrupt. +TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a [CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check "Wikipedia on Cyclic Redundancy Check" to each packet that allows the other computer to know if that packet is corrupt. When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. Whic solves the problem of corrupted and lost packets. From cd3eeb283b9249cdd136d150247c6696a0226d9b Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:28:19 +0200 Subject: [PATCH 14/80] Whic (sic) -> That --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 2934b4e9..81b45f54 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -24,7 +24,7 @@ With all that let's say we send packets ABCD in that order, it might be that at TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a [CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check "Wikipedia on Cyclic Redundancy Check" to each packet that allows the other computer to know if that packet is corrupt. -When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. Whic solves the problem of corrupted and lost packets. +When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. This ACKs also allows to regulate the speed with which packets are sent so if the clienthas less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them From 8799717003a503dfe8f2436da533facb5ce15125 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:32:59 +0200 Subject: [PATCH 15/80] rephrasing to avoid misconception about TCP --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 81b45f54..5572ba88 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -26,7 +26,7 @@ TCP is able to solve all of those problems. When TCP sends packets it numbers th When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. -This ACKs also allows to regulate the speed with which packets are sent so if the clienthas less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them +This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent so if the clienthas less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them As we see, using a TCP connection ensures that everything we send is received correctly on the other side. From 88cf52110250810bd94e85499c8c2b94ff403400 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:33:33 +0200 Subject: [PATCH 16/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 5572ba88..1a67d87c 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -26,7 +26,7 @@ TCP is able to solve all of those problems. When TCP sends packets it numbers th When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. -This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent so if the clienthas less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them +This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the clienthas less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them As we see, using a TCP connection ensures that everything we send is received correctly on the other side. From 20ec551c3f4b5b5fa188babc8dd1dd463116b9f7 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:33:52 +0200 Subject: [PATCH 17/80] inserted space to seperate words --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 1a67d87c..9cb083bb 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -26,7 +26,7 @@ TCP is able to solve all of those problems. When TCP sends packets it numbers th When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. -This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the clienthas less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them +This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the client has less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them As we see, using a TCP connection ensures that everything we send is received correctly on the other side. From bb2e60c61614340b8988a5f09be1da3bbe5a6599 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:34:20 +0200 Subject: [PATCH 18/80] till -> until --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 9cb083bb..d508be78 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -26,7 +26,7 @@ TCP is able to solve all of those problems. When TCP sends packets it numbers th When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. -This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the client has less bandwith than the server, the server can slow down sending packets till it arrives to the speed at which the client can receive them +This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the client has less bandwith than the server, the server can slow down sending packets until it arrives to the speed at which the client can receive them As we see, using a TCP connection ensures that everything we send is received correctly on the other side. From 058d1aed01ca1067975a0dbeb22b606417ab27f0 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:35:32 +0200 Subject: [PATCH 19/80] fixed minor spelling issues at end of sentence --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index d508be78..a2e0416c 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -26,7 +26,7 @@ TCP is able to solve all of those problems. When TCP sends packets it numbers th When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. -This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the client has less bandwith than the server, the server can slow down sending packets until it arrives to the speed at which the client can receive them +This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the client has less bandwith than the server, the server can slow down sending packets until it arrives at a speed at which the client can receive them. As we see, using a TCP connection ensures that everything we send is received correctly on the other side. From 95ec7188541c85babd35e1e3f462455166adef06 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:38:57 +0200 Subject: [PATCH 20/80] general spellcheck --- chapters/network/chapter.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index a2e0416c..dfdb0cf6 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -8,11 +8,11 @@ ## TCP vs UDP -TCP and UDP are 2 of the most used protocols to comunicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. +TCP and UDP are 2 of the most used protocols to communicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. ### TCP -The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a managable connection, UDP is more geared towards streams]** and resistant to errors, packet reordering and packet lose. Let's see what all that means. +The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a manageable connection, UDP is more geared towards streams]** and resistant to errors, packet reordering and packet lose. Let's see what all that means. To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send something it's usually divided into data packets. Each segment of the network might support a different packet size so it might subdivide our packets into smaller packets. A packet is just a segment of the information we are trying to send plus some headers depending on the protocol we are using. This division in packets is used among other things so it's easier to recover from errors. For example if we are sending a file and we sent it in one go, if some parts of it get corrupted we'll need to resend the full file again. Dividing it in packets and adding some headers to them allows us to detect errors per packet so we only need to resend the corrupted packets instead of the whole thing. @@ -22,11 +22,11 @@ Another problem is that packets might get corrupted on their way to the destinat With all that let's say we send packets ABCD in that order, it might be that at the other end we get something like GCB: packet A got corrupted and turned into G, packets B and C arrived ok but in the wrong order, and packet D was totally lost. -TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer recieves them. It also adds something called a [CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check "Wikipedia on Cyclic Redundancy Check" to each packet that allows the other computer to know if that packet is corrupt. +TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer receives them. It also adds something called a [CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check "Wikipedia on Cyclic Redundancy Check" to each packet that allows the other computer to know if that packet is corrupt. When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. -This ~~ACKs~~signaling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the client has less bandwith than the server, the server can slow down sending packets until it arrives at a speed at which the client can receive them. +This ~~ACKs~~signalling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the client has less bandwidth than the server, the server can slow down sending packets until it arrives at a speed at which the client can receive them. As we see, using a TCP connection ensures that everything we send is received correctly on the other side. @@ -70,17 +70,17 @@ If the protocol you are working with uses TCP and a delimiter, chances are you m tcpClient.setMessageDelimiter(myDelimiter); ``` -Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect ot it. +Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect to it. There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has it's own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. -While this is really practical, it means that if we have 2 computers behind NAT routers, it's imposible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP. +While this is really practical, it means that if we have 2 computers behind NAT routers, it's impossible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP. ### UDP UDP or **User Datagram Protocol**, is a non-connection datagram oriented, non error resistant protocol. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening in that machine and that port it will receive the message. -Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the subnetworks in the path from one computer to another, will arrive in one piece on the other side. In openFrameworks, if we do: +Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side. In openFrameworks, if we do: ```cpp string message = "Hello world!! this is an openFrameworks network message"; @@ -93,13 +93,13 @@ As we've said before, UDP is not resistant to errors so the packet may not arriv UDP might seem not useful but it has some advantages. Sometimes, we don't mind some packets being lost. For example, if we are sending a packet every few frames with the state of our application we don't mind if sometimes we don't receive one of them. It's also really hard to loose a packet on a local network, but if you need total reliability don't trust UDP, just use TCP. -Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the broadcast address we need to know the IP address of the machine from where we are sending and the subnetwork mask by doing a bit xor on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive... +Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the broadcast address we need to know the IP address of the machine from where we are sending and the sub-network mask by doing a bit XOR on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive... UDP, as we mentioned before, allows us to do NAT transversal using some clever tricks although is not something that can be done with raw UDP and requires a third party library. -A case where UDP might be preferable over TCP is in very time critical applications, you might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent so that might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resnet. We are usually talking of milliseconds here so as we've said it is usually not a problem. +A case where UDP might be preferable over TCP is in very time critical applications, you might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent so that might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resent. We are usually talking of milliseconds here so as we've said it is usually not a problem. -Another possibility is implementing part of the error recovery in TCP while using UDP, for example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement packet reordering in UDP simply by using a sequence number in each messsage and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message thath might arrive later needs to be processed before. +Another possibility is implementing part of the error recovery in TCP while using UDP, for example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. In general use TCP if you need your messages to arrive no matter what, when loosing even one packet might be critical and UDP if you need some of the most advanced uses like broadcasting, multicasting, NAT transversal, or when waiting for lost packets to be resent, even a few milliseconds, might make be critical for the application while loosing some packets is ok. From 36efcf604931445842bf2b396071f8cd560c6455 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:46:56 +0200 Subject: [PATCH 21/80] added period --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index dfdb0cf6..ab8481c6 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -6,7 +6,7 @@ *corrections by Brannon Dorsey* -## TCP vs UDP +## TCP vs. UDP TCP and UDP are 2 of the most used protocols to communicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. From b01e1b87175cbf9f67b1a81eee9e973f6564a7f2 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:52:36 +0200 Subject: [PATCH 22/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index ab8481c6..f8590211 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -30,7 +30,7 @@ This ~~ACKs~~signalling **[t: TCP uses sliding windows and congestion control to As we see, using a TCP connection ensures that everything we send is received correctly on the other side. -So why not just always use TCP? Well TCP has some limitations, for example TCP is connection oriented, that means that in order to communicate with another machine we need to open a connection explicitly to that machine and that machine only. +So why not just always use TCP? Well TCP has some limitations, for example TCP is connection oriented. That means that in order to communicate with another machine we need to open a connection explicitly to that machine and that machine only. TCP is also stream oriented. That means that we cannot send individual messages and expect them to arrive in one piece, they will arrive eventually but not exactly as we sent them. For example if we send something like: From a4e55841104c8e08cce0c300b8be1c72cc233389 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:53:09 +0200 Subject: [PATCH 23/80] , -> . --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index f8590211..169c12af 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -32,7 +32,7 @@ As we see, using a TCP connection ensures that everything we send is received co So why not just always use TCP? Well TCP has some limitations, for example TCP is connection oriented. That means that in order to communicate with another machine we need to open a connection explicitly to that machine and that machine only. -TCP is also stream oriented. That means that we cannot send individual messages and expect them to arrive in one piece, they will arrive eventually but not exactly as we sent them. For example if we send something like: +TCP is also stream oriented. That means that we cannot send individual messages and expect them to arrive in one piece. They will arrive eventually but not exactly as we sent them. For example if we send something like: "Hello world!! this is an openFrameworks network message" From 86afe7387976b491c649db94c1c3b6ea5f79845e Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:54:26 +0200 Subject: [PATCH 24/80] rephrasing to avoid dependent clause --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 169c12af..95dc283f 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -36,7 +36,7 @@ TCP is also stream oriented. That means that we cannot send individual messages "Hello world!! this is an openFrameworks network message" -On the other side, the application using TCP, we may receive it like: +The application using TCP in the other side may receive it like: "Hello w" "orld!" From 9631a3bdb472c1b71c2cfc4da1b613409fdc137a Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:55:16 +0200 Subject: [PATCH 25/80] There's -> There are (plural) --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 95dc283f..177a298d 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -46,7 +46,7 @@ The application using TCP in the other side may receive it like: "twork mess" "age" -We can't even be sure of which size those packets are going to have. There's tricks to send full messages, like adding a delimiter to them, for example openFrameworks when doing: +We can't even be sure of which size those packets are going to have. There are tricks to send full messages, like adding a delimiter to them, for example openFrameworks when doing: ```cpp tcpClient.send("Hello world!! this is an openFrameworks network message"); From 9f35bab1bd8f85ffab0d00ea0e0bb0cc283cfb42 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:56:55 +0200 Subject: [PATCH 26/80] split one sentence & rephrased for easier reading --- chapters/network/chapter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 177a298d..5f1b446e 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -46,13 +46,13 @@ The application using TCP in the other side may receive it like: "twork mess" "age" -We can't even be sure of which size those packets are going to have. There are tricks to send full messages, like adding a delimiter to them, for example openFrameworks when doing: +We can't even be sure of which size those packets are going to have. There are tricks to send full messages, like adding a delimiter to them. For example openFrameworks when sending: ```cpp tcpClient.send("Hello world!! this is an openFrameworks network message"); ``` -Internally is sending: +actually (internally) sends: "Hello world!! this is an openFrameworks network message[/TCP]\0" From 9f131538b9927f1ba852aa08e68d64ce2301af08 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 11:58:52 +0200 Subject: [PATCH 27/80] corrected TCP message delimiter --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 5f1b446e..075c4419 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -56,7 +56,7 @@ actually (internally) sends: "Hello world!! this is an openFrameworks network message[/TCP]\0" -The last `\0` is actually added for compatibility reasons with old versions of flash! The `[\TCP]` allows the other side to read the stream until it receives the full message. So when you use: +The last `\0` is actually added for compatibility reasons with old versions of flash! The `[/TCP]` allows the other side to read the stream until it receives the full message. So when you use: ```cpp string message = tcpServer.receive(); From 351dcc5db45b225b2aabfbf383f7150a2887ae19 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 12:00:09 +0200 Subject: [PATCH 28/80] rephrased for easier reading --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 075c4419..6dbc1b0e 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -62,7 +62,7 @@ The last `\0` is actually added for compatibility reasons with old versions of f string message = tcpServer.receive(); ``` -Internally ofxTCPCLient/Server will read the stream, keep the partial messages in memory, and wait until it gets the delimiter before returning a full message. This is done transparently, but if you are interfacing with some other protocol coming from a non OF application you might need to do this your self by using `sendRaw()` `sendRawMsg()` `receiveRaw()` and `receiveRawMsg()` which don't send or expect a terminator. +The ofxTCPCLient/Server will internally read the stream, keep the partial messages in memory, and wait until it gets the delimiter before returning a full message. This is done transparently, but if you are interfacing with some other protocol coming from a non OF application you might need to do this your self by using `sendRaw()` `sendRawMsg()` `receiveRaw()` and `receiveRawMsg()` which don't send or expect a terminator. If the protocol you are working with uses TCP and a delimiter, chances are you might be able to use this same trick by using: From 23bac9f9a09a6bfb8b3644e688adb503ed64e2cc Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 12:14:28 +0200 Subject: [PATCH 29/80] added wikipedia link to Adobe Flash --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 6dbc1b0e..921644e2 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -56,7 +56,7 @@ actually (internally) sends: "Hello world!! this is an openFrameworks network message[/TCP]\0" -The last `\0` is actually added for compatibility reasons with old versions of flash! The `[/TCP]` allows the other side to read the stream until it receives the full message. So when you use: +The last `\0` is actually added for compatibility reasons with old versions of [Flash](https://en.wikipedia.org/wiki/Adobe_Flash "Wikipedia link on Adobe Flash"). The `[/TCP]` allows the other side to read the stream until it receives the full message. So when you use: ```cpp string message = tcpServer.receive(); From d16bbfa3123e6f1369710fd384ac1e07f8af4cc9 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 13:15:08 +0200 Subject: [PATCH 30/80] made IP and NAT specific section at the beginning --- chapters/network/chapter.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 921644e2..4fedf13a 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -6,6 +6,15 @@ *corrections by Brannon Dorsey* +## IP and NAT + +Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect to it. + +There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has it's own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. + +While this is really practical, it means that if we have 2 computers behind NAT routers, it's impossible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP. + + ## TCP vs. UDP TCP and UDP are 2 of the most used protocols to communicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). TCP and UDP belong to layer 4, the transport layer, and are usually the most used in OF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. @@ -70,12 +79,6 @@ If the protocol you are working with uses TCP and a delimiter, chances are you m tcpClient.setMessageDelimiter(myDelimiter); ``` -Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect to it. - -There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has it's own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. - -While this is really practical, it means that if we have 2 computers behind NAT routers, it's impossible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP. - ### UDP UDP or **User Datagram Protocol**, is a non-connection datagram oriented, non error resistant protocol. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening in that machine and that port it will receive the message. From 13e74fe948c4bf6dd542ee20e4322abf341737b6 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 13:17:23 +0200 Subject: [PATCH 31/80] stroked out original text, left note --- chapters/network/chapter.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 4fedf13a..7c1eee67 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -79,6 +79,13 @@ If the protocol you are working with uses TCP and a delimiter, chances are you m tcpClient.setMessageDelimiter(myDelimiter); ``` +~~Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect to it. + +There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has it's own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. + +While this is really practical, it means that if we have 2 computers behind NAT routers, it's impossible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP.~~ **[t: i moved this section to the beginning and expanded on it]** + + ### UDP UDP or **User Datagram Protocol**, is a non-connection datagram oriented, non error resistant protocol. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening in that machine and that port it will receive the message. From 3012fdf1784c21d90c3a5f24b568a92f462b223a Mon Sep 17 00:00:00 2001 From: tpltnt Date: Fri, 24 Apr 2015 14:50:25 +0200 Subject: [PATCH 32/80] added section about IP, sockets, DNS and NAT --- chapters/network/chapter.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 7c1eee67..34a421c3 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -2,17 +2,16 @@ *by [Arturo Castro](http://arturocastro.net)* - +*extensions by tpltnt* *corrections by Brannon Dorsey* +This chapter gives a brief overview over the things you need to know to use computer networks with openFrameworks. Do not be afraid if you do not understand all the concepts. The idea is more to give you a basic understanding, some terminology and references so you can explore this topic and go deeper when you want (or need) to. ## IP and NAT -Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect to it. - -There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has it's own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. - -While this is really practical, it means that if we have 2 computers behind NAT routers, it's impossible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP. +In order to connect to a computer on the internet or your local network you need to be able to identify the machine. This is done by what is called an [IP address](https://en.wikipedia.org/wiki/IP_address "Wikipedia on IP addresses"). This is label is used as the source and destination address when sending data packets. These data packets encapsulate chunks of the information (like a file or a text string) you want to send (later more on that). In order to send data to a particular application, you also have to tell the machine where your data packets and the desired application meet. This meeting point is called a ["port"](https://en.wikipedia.org/wiki/Port_%28computer_networking%29 "Wikipedia on ports (for networking)"). For reference: The combination of an IP and a port is called a ["socket"](https://en.wikipedia.org/wiki/Network_socket "Wikipedia on network sockets"). IP only handles only the routing part of networking while other protocols handle other functionality. TCP and UDP for example handle the data transmission (see below). All this functionality is often talked about in terms of "layers" (of abstraction) and the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). +The IP protocol comes in two flavors: [IPv4](https://en.wikipedia.org/wiki/IPv4 "Wikipedia on IPv4") (still very common), where addresses look like "93.184.216.34" (so called ["dot-decima"](https://en.wikipedia.org/wiki/Dot-decimal_notation "Wikipedia on dot-decimal notation") or "dotted quad" notation) and [IPv6](https://en.wikipedia.org/wiki/IPv6 "Wikipedia on IPv6") (the current version), where addresses look like "2001:500:8c::53". An application ususally listens on a predetermined port and waits for data to arrive. For some applications (like webservers) these are (informally) [standardized](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml "IANA list of port numbers") (like ports 80 and 443), others (like maybe yours) just picks a free port number. As long as you do not pick one already in use, this is not (too much) of a problem. No two processes can use ("bind to") the same port number (and protocol), so there is only one application listening on port 80 for TCP connections (but another one might listen on port 80 for UDP connections). This is usually enforced by the operating system. The combination of IP and port is written as "93.184.216.34:80" in the case of IPv4 and "[2001:500:8c::53]:80" in the case of IPv6. Since people are bad at remembering long strings of random looking numbers and characters, there is a system in place to map [domain names](https://en.wikipedia.org/wiki/Domain_name "Wikipedia on domain names") into IP addresses. It is called [Domain Name System or DNS](https://en.wikipedia.org/wiki/Domain_Name_System "Wikipedia on the Domain Name System"). Here the IP/port pair (or socket) is notated as "[example.net]:80". +Not all IP addresses can be reached. There is a [range of IPv4 addressed](https://tools.ietf.org/html/rfc1918 "RFC 1918: Address Allocation for Private Internets") and a [range of IPv6 addresses](https://tools.ietf.org/html/rfc4193 "RFC 4193: Unique Local IPv6 Unicast Addresses") which are called "private". That means that your [router](https://en.wikipedia.org/wiki/Router_%28computing%29 "Wikipedia on routers") will not pass on packets coming from these ranges into the internet. Your computer at home probably has a private IPv4 address of "192.168.x.x" or "10.x.x.x". That means that machines in your local network can talk to it, but no one from the outside. Your router as a public IP address and translates the packets with your requests to outside resources (e.g. when you surf the web). The router does so called "Network Address Translation (NAT)"](https://en.wikipedia.org/wiki/Network_address_translation "Wikipedia on Network Address Translation"). It takes addresses from one address range (your private one) and translates them to another one (the public range) back and forth (for an established connection). Since your ["Internet Service Provider (ISP)"](https://en.wikipedia.org/wiki/Internet_service_provider "Wikipedia on Internet Service Providers") assigns the public IP to your router, you have litte control over it. This in itself is quite useful from a management perspective, but it also means that two devices behind NAT usually can not talk to each other (since they are ususally not part of DNS and so called ["port forwarding"](https://en.wikipedia.org/wiki/Port_forwarding "Wikipedia on port forwarding") is not enabled by default on your router). To get around this you either have to enable port forwarding and know the IP of your destination router or use addons like [ofxNice](https://github.com/arturoc/ofxNice) that allows you to do NAT transversal (but it will only work for UDP). ## TCP vs. UDP From 479b64ffa01478e265827efedbcbe31ccfc5a677 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sat, 25 Apr 2015 08:07:43 +0200 Subject: [PATCH 33/80] rephrased sentence for simplification --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 34a421c3..9b0e705c 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -87,7 +87,7 @@ While this is really practical, it means that if we have 2 computers behind NAT ### UDP -UDP or **User Datagram Protocol**, is a non-connection datagram oriented, non error resistant protocol. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening in that machine and that port it will receive the message. +UDP or **User Datagram Protocol**, is a ~~non-connection datagram oriented, non error resistant protocol~~ protocol oriented towards single individual messages and can not easily recover from transmission errors **[t: rephrasing for easier understanding & to avoid negations]**. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening in that machine and that port it will receive the message. Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side. In openFrameworks, if we do: From 41433686713ad118805d9a907378ddb88b3a0a41 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sat, 25 Apr 2015 08:08:14 +0200 Subject: [PATCH 34/80] in -> on --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 9b0e705c..cf279d4a 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -87,7 +87,7 @@ While this is really practical, it means that if we have 2 computers behind NAT ### UDP -UDP or **User Datagram Protocol**, is a ~~non-connection datagram oriented, non error resistant protocol~~ protocol oriented towards single individual messages and can not easily recover from transmission errors **[t: rephrasing for easier understanding & to avoid negations]**. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening in that machine and that port it will receive the message. +UDP or **User Datagram Protocol**, is a ~~non-connection datagram oriented, non error resistant protocol~~ protocol oriented towards single individual messages and can not easily recover from transmission errors **[t: rephrasing for easier understanding & to avoid negations]**. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening on that machine and that port it will receive the message. Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side. In openFrameworks, if we do: From a8a989577ad89a0f2fb11fff86f403ab72ad1f14 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sat, 25 Apr 2015 20:17:20 +0200 Subject: [PATCH 35/80] there's -> there is --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index cf279d4a..d1b900b5 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -87,7 +87,7 @@ While this is really practical, it means that if we have 2 computers behind NAT ### UDP -UDP or **User Datagram Protocol**, is a ~~non-connection datagram oriented, non error resistant protocol~~ protocol oriented towards single individual messages and can not easily recover from transmission errors **[t: rephrasing for easier understanding & to avoid negations]**. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there's a process listening on that machine and that port it will receive the message. +UDP or **User Datagram Protocol**, is a ~~non-connection datagram oriented, non error resistant protocol~~ protocol oriented towards single individual messages and can not easily recover from transmission errors **[t: rephrasing for easier understanding & to avoid negations]**. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there is a process listening on that machine and that port it will receive the message. Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side. In openFrameworks, if we do: From ec20d95a6ff32696e15e4e2ac6dc3ec06b26fe9c Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 08:41:35 +0200 Subject: [PATCH 36/80] extended sentences for better understanding of UDP + MTU (as concepts) --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index d1b900b5..9fb014ee 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -89,7 +89,7 @@ While this is really practical, it means that if we have 2 computers behind NAT UDP or **User Datagram Protocol**, is a ~~non-connection datagram oriented, non error resistant protocol~~ protocol oriented towards single individual messages and can not easily recover from transmission errors **[t: rephrasing for easier understanding & to avoid negations]**. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there is a process listening on that machine and that port it will receive the message. -Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side. In openFrameworks, if we do: +~~Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side.~~ The packet size supported by the networks along the transmission path is central to datagram oriented protocols like UDP. Each message has to be smaller (or equal) to the Maximum Transmission Unit of a connection/path in order to be passed on. If a packet is larger than the MTU it (theoretically) should be broken up, but since UDP (unlike TCP) has no information on packet order or (re-)assembly, the packet just gets dropped. **[t: rephrased & extended for better understanding]** In openFrameworks, if we do: ```cpp string message = "Hello world!! this is an openFrameworks network message"; From 4f0100fc513be3cc28d0b96556401c2fa64a386e Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 08:43:12 +0200 Subject: [PATCH 37/80] advice -> notice --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 9fb014ee..4e6e7155 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -98,7 +98,7 @@ udpManager.SendAll(message, message.size()); The other side will receive that message in one piece. That is, if it receives it at all. -As we've said before, UDP is not resistant to errors so the packet may not arrive. It may get corrupted and there's no way to recover it. If we send several packets they may arrive in a different order then they were sent. UDP also doesn't adjust for bandwidth, so if one side is sending faster than what the other side can receive, or even if it fills the local buffers while sending, some packets will get lost. What's worse, we won't receive any advice that they got lost, nor in the sender nor in the receiver. +As we've said before, UDP is not resistant to errors so the packet may not arrive. It may get corrupted and there's no way to recover it. If we send several packets they may arrive in a different order then they were sent. UDP also doesn't adjust for bandwidth, so if one side is sending faster than what the other side can receive, or even if it fills the local buffers while sending, some packets will get lost. What's worse, we won't receive any notice that they got lost, nor in the sender nor in the receiver. UDP might seem not useful but it has some advantages. Sometimes, we don't mind some packets being lost. For example, if we are sending a packet every few frames with the state of our application we don't mind if sometimes we don't receive one of them. It's also really hard to loose a packet on a local network, but if you need total reliability don't trust UDP, just use TCP. From 4266a52f4931e9ca1d3672f6831a3e9735600cc9 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 08:44:18 +0200 Subject: [PATCH 38/80] removed comma --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 4e6e7155..de2c96ee 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -100,7 +100,7 @@ The other side will receive that message in one piece. That is, if it receives i As we've said before, UDP is not resistant to errors so the packet may not arrive. It may get corrupted and there's no way to recover it. If we send several packets they may arrive in a different order then they were sent. UDP also doesn't adjust for bandwidth, so if one side is sending faster than what the other side can receive, or even if it fills the local buffers while sending, some packets will get lost. What's worse, we won't receive any notice that they got lost, nor in the sender nor in the receiver. -UDP might seem not useful but it has some advantages. Sometimes, we don't mind some packets being lost. For example, if we are sending a packet every few frames with the state of our application we don't mind if sometimes we don't receive one of them. It's also really hard to loose a packet on a local network, but if you need total reliability don't trust UDP, just use TCP. +UDP might seem not useful but it has some advantages. Sometimes we don't mind some packets being lost. For example, if we are sending a packet every few frames with the state of our application we don't mind if sometimes we don't receive one of them. It's also really hard to loose a packet on a local network, but if you need total reliability don't trust UDP, just use TCP. Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the broadcast address we need to know the IP address of the machine from where we are sending and the sub-network mask by doing a bit XOR on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive... From 71ae6c7cfbd8d5e7479d3e8b4adf3d4ae44086c1 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 08:48:27 +0200 Subject: [PATCH 39/80] hint at difference for IPv4 vs. IPv6 broadcast addresses --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index de2c96ee..f7a80df6 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -102,7 +102,7 @@ As we've said before, UDP is not resistant to errors so the packet may not arriv UDP might seem not useful but it has some advantages. Sometimes we don't mind some packets being lost. For example, if we are sending a packet every few frames with the state of our application we don't mind if sometimes we don't receive one of them. It's also really hard to loose a packet on a local network, but if you need total reliability don't trust UDP, just use TCP. -Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the broadcast address we need to know the IP address of the machine from where we are sending and the sub-network mask by doing a bit XOR on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive... +Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the IPv4 broadcast address (IPv6 has a different mechanism) we need to know the IP address of the machine from where we are sending and the sub-network mask by doing a bit XOR on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive... UDP, as we mentioned before, allows us to do NAT transversal using some clever tricks although is not something that can be done with raw UDP and requires a third party library. From b91fbf7745b98c9bfe2956fc3e8934d344c28a3d Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:02:58 +0200 Subject: [PATCH 40/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index f7a80df6..2ee38e10 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -106,7 +106,7 @@ Some of the advantages of UDP come from the fact that is connectionless. That me UDP, as we mentioned before, allows us to do NAT transversal using some clever tricks although is not something that can be done with raw UDP and requires a third party library. -A case where UDP might be preferable over TCP is in very time critical applications, you might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent so that might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resent. We are usually talking of milliseconds here so as we've said it is usually not a problem. +A case where UDP might be preferable over TCP is in very time critical applications. You might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent so that might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resent. We are usually talking of milliseconds here so as we've said it is usually not a problem. Another possibility is implementing part of the error recovery in TCP while using UDP, for example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. From 7afe3c36bda20c56ffafdfb8172a381bd6d29ab3 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:04:05 +0200 Subject: [PATCH 41/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 2ee38e10..e3504236 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -106,7 +106,7 @@ Some of the advantages of UDP come from the fact that is connectionless. That me UDP, as we mentioned before, allows us to do NAT transversal using some clever tricks although is not something that can be done with raw UDP and requires a third party library. -A case where UDP might be preferable over TCP is in very time critical applications. You might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent so that might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resent. We are usually talking of milliseconds here so as we've said it is usually not a problem. +A case where UDP might be preferable over TCP is in very time critical applications. You might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent. That might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resent. We are usually talking of milliseconds here so as we've said it is usually not a problem. Another possibility is implementing part of the error recovery in TCP while using UDP, for example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. From 3920e36250d2b85837bd3a7f8b9fae523a4fcc3b Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:06:09 +0200 Subject: [PATCH 42/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index e3504236..f31e5715 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -108,7 +108,7 @@ UDP, as we mentioned before, allows us to do NAT transversal using some clever t A case where UDP might be preferable over TCP is in very time critical applications. You might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent. That might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resent. We are usually talking of milliseconds here so as we've said it is usually not a problem. -Another possibility is implementing part of the error recovery in TCP while using UDP, for example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. +Another possibility is implementing part of the error recovery in TCP while using UDP. For example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. In general use TCP if you need your messages to arrive no matter what, when loosing even one packet might be critical and UDP if you need some of the most advanced uses like broadcasting, multicasting, NAT transversal, or when waiting for lost packets to be resent, even a few milliseconds, might make be critical for the application while loosing some packets is ok. From 4c7f44c085193e4373f58306cd40d20e4dcf9a5e Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:06:31 +0200 Subject: [PATCH 43/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index f31e5715..db5bc925 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -108,7 +108,7 @@ UDP, as we mentioned before, allows us to do NAT transversal using some clever t A case where UDP might be preferable over TCP is in very time critical applications. You might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent. That might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resent. We are usually talking of milliseconds here so as we've said it is usually not a problem. -Another possibility is implementing part of the error recovery in TCP while using UDP. For example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive, in those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. +Another possibility is implementing part of the error recovery in TCP while using UDP. For example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive. In those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. In general use TCP if you need your messages to arrive no matter what, when loosing even one packet might be critical and UDP if you need some of the most advanced uses like broadcasting, multicasting, NAT transversal, or when waiting for lost packets to be resent, even a few milliseconds, might make be critical for the application while loosing some packets is ok. From 680d4e7c732584240692603500d95d26930edbde Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:07:40 +0200 Subject: [PATCH 44/80] split one sentence into two + slight rephrasing --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index db5bc925..ad2a3c44 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -108,7 +108,7 @@ UDP, as we mentioned before, allows us to do NAT transversal using some clever t A case where UDP might be preferable over TCP is in very time critical applications. You might have heard that UDP is faster than TCP. That is not exactly true, at least is not that fast to make much difference. The real difference is that when using TCP, if a packet gets corrupted or lost the next messages won't get delivered to the application until the lost one is resent. That might introduce a slight delay. In most applications that delay is not noticeable but in some very time critical applications we might prefer to loose some packets than having to wait for them to be resent. We are usually talking of milliseconds here so as we've said it is usually not a problem. -Another possibility is implementing part of the error recovery in TCP while using UDP. For example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive. In those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer so we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. +Another possibility is implementing part of the error recovery in TCP while using UDP. For example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive. In those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer. With this approach we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. In general use TCP if you need your messages to arrive no matter what, when loosing even one packet might be critical and UDP if you need some of the most advanced uses like broadcasting, multicasting, NAT transversal, or when waiting for lost packets to be resent, even a few milliseconds, might make be critical for the application while loosing some packets is ok. From bc81dbb9609d23b606ad18556f6d54eb34e4716a Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:08:58 +0200 Subject: [PATCH 45/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index ad2a3c44..0ff042b6 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -110,7 +110,7 @@ A case where UDP might be preferable over TCP is in very time critical applicati Another possibility is implementing part of the error recovery in TCP while using UDP. For example we might not mind loosing some packets or getting some of them corrupt but we care about the order in which they arrive. In those cases we can implement packet reordering in UDP simply by using a sequence number in each message and reorder the packets in the destination by having a buffer. With this approach we can wait a little before actually processing a message to see if any other message that might arrive later needs to be processed before. -In general use TCP if you need your messages to arrive no matter what, when loosing even one packet might be critical and UDP if you need some of the most advanced uses like broadcasting, multicasting, NAT transversal, or when waiting for lost packets to be resent, even a few milliseconds, might make be critical for the application while loosing some packets is ok. +In general use TCP if you need your messages to arrive no matter what, when loosing even one packet might be critical. Use UDP if you need some of the most advanced uses like broadcasting, multicasting, NAT transversal, or when waiting for lost packets to be resent, even a few milliseconds, might make be critical for the application while loosing some packets is ok. ## OSC From 65c571fc8216d4b72037cde7572f516fe89a34b7 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:10:07 +0200 Subject: [PATCH 46/80] there's -> there are (plural) --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 0ff042b6..daabf935 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -118,7 +118,7 @@ OSC is an application level protocol. It is of a higher level than UDP or TCP, a It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. -Another advantage of using OSC is that there's lots of commercial and open source projects that support OSC. Using OSC you might be able to easily control some other software or receive results from it, for example you can have a Pure Data patch to generate audio and control it's parameters from openFrameworks by sending OSC messages to it. +Another advantage of using OSC is that there are lots of commercial and open source projects that support OSC. Using OSC you might be able to easily control some other software or receive results from it, for example you can have a Pure Data patch to generate audio and control it's parameters from openFrameworks by sending OSC messages to it. As well as OSC there's other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there's protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. From c4b89fda8c5134eb8d55d68083123110f6759145 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:11:09 +0200 Subject: [PATCH 47/80] split one sentence into two + slight rephrasing --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index daabf935..d4cc9cea 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -118,7 +118,7 @@ OSC is an application level protocol. It is of a higher level than UDP or TCP, a It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. -Another advantage of using OSC is that there are lots of commercial and open source projects that support OSC. Using OSC you might be able to easily control some other software or receive results from it, for example you can have a Pure Data patch to generate audio and control it's parameters from openFrameworks by sending OSC messages to it. +Another advantage of using OSC is that there are lots of commercial and open source projects that support OSC. Using OSC you might be able to easily control some other software or receive results from it. You can, for example, have a Pure Data patch to generate audio and control it's parameters from openFrameworks by sending OSC messages to it. As well as OSC there's other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there's protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. From f6c7235d0cd6a86d0a30a5e5ca2c833808808db8 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:12:54 +0200 Subject: [PATCH 48/80] spelled out OSC --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index d4cc9cea..8a6c0d3b 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -114,7 +114,7 @@ In general use TCP if you need your messages to arrive no matter what, when loos ## OSC -OSC is an application level protocol. It is of a higher level than UDP or TCP, and it's main characteristic is that it allows to send types like int, float, string... without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. +Open Sound Control (OSC) is an application level protocol. It is of a higher level than UDP or TCP, and it's main characteristic is that it allows to send types like int, float, string... without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. From 9b988d255dd7df6011ed083f4bfff0515b8f002c Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:13:37 +0200 Subject: [PATCH 49/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 8a6c0d3b..25acfbb7 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -114,7 +114,7 @@ In general use TCP if you need your messages to arrive no matter what, when loos ## OSC -Open Sound Control (OSC) is an application level protocol. It is of a higher level than UDP or TCP, and it's main characteristic is that it allows to send types like int, float, string... without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. +Open Sound Control (OSC) is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string... without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. From b6d22c5a6c51d4b157e57ba54bb86da67db8df3e Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:14:55 +0200 Subject: [PATCH 50/80] split one sentence into two + rephrasing + extending --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 25acfbb7..fc38bbce 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -114,7 +114,7 @@ In general use TCP if you need your messages to arrive no matter what, when loos ## OSC -Open Sound Control (OSC) is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string... without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. +Open Sound Control (OSC) is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. From 1df7120b68cc8ac11fc6a3ad365385cdceaec7ec Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:16:26 +0200 Subject: [PATCH 51/80] there's -> there are (plural) --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index fc38bbce..c8c36798 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -120,6 +120,6 @@ It's usage in openFrameworks is really simple, so just check the examples in the Another advantage of using OSC is that there are lots of commercial and open source projects that support OSC. Using OSC you might be able to easily control some other software or receive results from it. You can, for example, have a Pure Data patch to generate audio and control it's parameters from openFrameworks by sending OSC messages to it. -As well as OSC there's other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there's protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. +As well as OSC there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there's protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. From b93fd4cceeb9dd61d70a98149330a26cbd1c18b4 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:17:00 +0200 Subject: [PATCH 52/80] there's -> there are (plural) --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index c8c36798..6f25a4c4 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -120,6 +120,6 @@ It's usage in openFrameworks is really simple, so just check the examples in the Another advantage of using OSC is that there are lots of commercial and open source projects that support OSC. Using OSC you might be able to easily control some other software or receive results from it. You can, for example, have a Pure Data patch to generate audio and control it's parameters from openFrameworks by sending OSC messages to it. -As well as OSC there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there's protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. +As well as OSC there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there are protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. From 31feb6254d2370f74ff97ee8ce758cda0260902c Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:17:54 +0200 Subject: [PATCH 53/80] split one sentence into two --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 6f25a4c4..a635c301 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -120,6 +120,6 @@ It's usage in openFrameworks is really simple, so just check the examples in the Another advantage of using OSC is that there are lots of commercial and open source projects that support OSC. Using OSC you might be able to easily control some other software or receive results from it. You can, for example, have a Pure Data patch to generate audio and control it's parameters from openFrameworks by sending OSC messages to it. -As well as OSC there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there are protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. +As well as OSC there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there are protocols like RTP that already solve or at least mitigate all the complications that it involves. Using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. From 5e3de64618d7d6ff010e4165f6c0a8a1e4283b4f Mon Sep 17 00:00:00 2001 From: tpltnt Date: Sun, 26 Apr 2015 09:18:22 +0200 Subject: [PATCH 54/80] removed trailing whitespace --- chapters/network/chapter.md | 1 - 1 file changed, 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index a635c301..55175be8 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -122,4 +122,3 @@ Another advantage of using OSC is that there are lots of commercial and open sou As well as OSC there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there are protocols like RTP that already solve or at least mitigate all the complications that it involves. Using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. - From 63aa632d1d759bfc59b2962d0885f185cbeb6eb0 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:10:15 +0200 Subject: [PATCH 55/80] wikipedia MTU link added --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index e1d4dd19..065bc127 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -89,7 +89,7 @@ While this is really practical, it means that if we have 2 computers behind NAT UDP or **User Datagram Protocol**, is a ~~non-connection datagram oriented, non error resistant protocol~~ protocol oriented towards single individual messages and can not easily recover from transmission errors **[t: rephrasing for easier understanding & to avoid negations]**. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there is a process listening on that machine and that port it will receive the message. -~~Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side.~~ The packet size supported by the networks along the transmission path is central to datagram oriented protocols like UDP. Each message has to be smaller (or equal) to the Maximum Transmission Unit of a connection/path in order to be passed on. If a packet is larger than the MTU it (theoretically) should be broken up, but since UDP (unlike TCP) has no information on packet order or (re-)assembly, the packet just gets dropped. **[t: rephrased & extended for better understanding]** In openFrameworks, if we do: +~~Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side.~~ The packet size supported by the networks along the transmission path is central to datagram oriented protocols like UDP. Each message has to be smaller (or equal) to the [Maximum Transmission Unit](https://en.wikipedia.org/wiki/Maximum_transmission_unit "Wikipedia on maximum transmission unit") of a connection/path in order to be passed on. If a packet is larger than the MTU it (theoretically) should be broken up, but since UDP (unlike TCP) has no information on packet order or (re-)assembly, the packet just gets dropped. **[t: rephrased & extended for better understanding]** In openFrameworks, if we do: ```cpp string message = "Hello world!! this is an openFrameworks network message"; From d987f4ae755052554806fea65e19037f1988ffa9 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:11:32 +0200 Subject: [PATCH 56/80] XOR -> math --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 065bc127..f4b38712 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -103,7 +103,7 @@ As we've said before, UDP is not resistant to errors so the packet may not arriv UDP might seem not useful but it has some advantages. First, it is fast! Since UDP doesn't require feedback (e.g. ACKs) and only minimal header information, there are less bytes to send. In many cases, this speed is more important than reliability. For example, if we are sending a packet every few frames with the state of our application we don't mind if one or two frames is lost because the destination will be updated with the next packet it receives. It's also really rare to loose UDP packets on a local network. Thus, if you need to send your packets very quickly (also known as low-latency) and you don't mind if a few packets are lost, UDP may be right for you. If your application requires confirmation that each and every byte arrived at its destination, you'll need to use TCP. -Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the IPv4 broadcast address (IPv6 has a different mechanism) we need to know the IP address of the machine from where we are sending and the sub-network mask by doing a bit XOR on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive. +Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the IPv4 broadcast address (IPv6 has a different mechanism) we need to know the IP address of the machine from where we are sending and the sub-network mask by doing a bit of math on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive. UDP, as we mentioned before, allows us to do NAT transversal using some clever tricks although is not something that can be done with raw UDP and requires a third party library. From 5c7d02f0aeb0fea5f8633bb726a99fd63ece7e68 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:13:15 +0200 Subject: [PATCH 57/80] wikipedia link on multicast added --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index f4b38712..bb3de471 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -103,7 +103,7 @@ As we've said before, UDP is not resistant to errors so the packet may not arriv UDP might seem not useful but it has some advantages. First, it is fast! Since UDP doesn't require feedback (e.g. ACKs) and only minimal header information, there are less bytes to send. In many cases, this speed is more important than reliability. For example, if we are sending a packet every few frames with the state of our application we don't mind if one or two frames is lost because the destination will be updated with the next packet it receives. It's also really rare to loose UDP packets on a local network. Thus, if you need to send your packets very quickly (also known as low-latency) and you don't mind if a few packets are lost, UDP may be right for you. If your application requires confirmation that each and every byte arrived at its destination, you'll need to use TCP. -Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the IPv4 broadcast address (IPv6 has a different mechanism) we need to know the IP address of the machine from where we are sending and the sub-network mask by doing a bit of math on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use multicast if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive. +Some of the advantages of UDP come from the fact that is connectionless. That means, among other things, that we can broadcast messages to all of the computers in the local network using a broadcast address. To calculate the IPv4 broadcast address (IPv6 has a different mechanism) we need to know the IP address of the machine from where we are sending and the sub-network mask by doing a bit of math on them you get the broadcast address. For example, if the IP address of our machine is 192.168.0.3, and our network mask is 255.255.255.0, the broadcast address will be 192.168.0.255. We can also use [multicast](https://en.wikipedia.org/wiki/Multicast "Wikipedia on Multicast") if we are working across networks although that's more difficult to setup. We can reuse ports, so we can have more than one process in the same machine using the same port, or use the same port to send and receive. UDP, as we mentioned before, allows us to do NAT transversal using some clever tricks although is not something that can be done with raw UDP and requires a third party library. From 63b649d24edd1a2f8c0e7f9ea382d85e997152de Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:14:48 +0200 Subject: [PATCH 58/80] linked OSC website --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index bb3de471..a8959b6c 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -115,7 +115,7 @@ In general use TCP if you need your messages to arrive no matter what, when loos ## OSC -Open Sound Control (OSC) is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. +[Open Sound Control (OSC)](http://opensoundcontrol.org/ "OSC website") is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. From fbcf22f4b3bb3a8079b2c20a2c2807c1bb3128a2 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:28:59 +0200 Subject: [PATCH 59/80] added examples of OSC implementations --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index a8959b6c..ae6dffc0 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -119,6 +119,6 @@ In general use TCP if you need your messages to arrive no matter what, when loos It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. -One major advantage of using OSC is that there are lots of commercial and open source projects that support OSC. OSC allows your software to easily control (or be controlled) by another piece of software. For example, in a performance you might want a Pure Data patch to generate audio and openFrameworks to generate video. During the performance, the two programs could control each other's parameters by exchanging OSC messages. +One major advantage of using OSC is that there are lots of commercial and open source projects that support OSC (like [monome](http://monome.org/ "monome controller website"), [midibox](http://www.midibox.org/ "midibox website"), [LiVES](http://lives.sourceforge.net/ "LiVES video editor and VJ tool website") or [Csound](http://csound.github.io/ "CSound website")). OSC allows your software to easily control (or be controlled) by another piece of software. For example, in a performance you might want a Pure Data patch to generate audio and openFrameworks to generate video. During the performance, the two programs could control each other's parameters by exchanging OSC messages. In addition to OSC, there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there are protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. From fead51ed6d192292f032a8e7b7d35331ae1b9859 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:29:56 +0200 Subject: [PATCH 60/80] added Pd website link --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index ae6dffc0..74c6583a 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -119,6 +119,6 @@ In general use TCP if you need your messages to arrive no matter what, when loos It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. -One major advantage of using OSC is that there are lots of commercial and open source projects that support OSC (like [monome](http://monome.org/ "monome controller website"), [midibox](http://www.midibox.org/ "midibox website"), [LiVES](http://lives.sourceforge.net/ "LiVES video editor and VJ tool website") or [Csound](http://csound.github.io/ "CSound website")). OSC allows your software to easily control (or be controlled) by another piece of software. For example, in a performance you might want a Pure Data patch to generate audio and openFrameworks to generate video. During the performance, the two programs could control each other's parameters by exchanging OSC messages. +One major advantage of using OSC is that there are lots of commercial and open source projects that support OSC (like [monome](http://monome.org/ "monome controller website"), [midibox](http://www.midibox.org/ "midibox website"), [LiVES](http://lives.sourceforge.net/ "LiVES video editor and VJ tool website") or [Csound](http://csound.github.io/ "CSound website")). OSC allows your software to easily control (or be controlled) by another piece of software. For example, in a performance you might want a [Pure Data](http://puredata.info/ "Pure Data website") patch to generate audio and openFrameworks to generate video. During the performance, the two programs could control each other's parameters by exchanging OSC messages. In addition to OSC, there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there are protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. From 15ba0d41fc56e6ff0f2ec82dde01bc66ddf82e7c Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:32:05 +0200 Subject: [PATCH 61/80] added wikipedia RTP link --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 74c6583a..3a6bc8fc 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -121,4 +121,4 @@ It's usage in openFrameworks is really simple, so just check the examples in the One major advantage of using OSC is that there are lots of commercial and open source projects that support OSC (like [monome](http://monome.org/ "monome controller website"), [midibox](http://www.midibox.org/ "midibox website"), [LiVES](http://lives.sourceforge.net/ "LiVES video editor and VJ tool website") or [Csound](http://csound.github.io/ "CSound website")). OSC allows your software to easily control (or be controlled) by another piece of software. For example, in a performance you might want a [Pure Data](http://puredata.info/ "Pure Data website") patch to generate audio and openFrameworks to generate video. During the performance, the two programs could control each other's parameters by exchanging OSC messages. -In addition to OSC, there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there are protocols like RTP that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. +In addition to OSC, there are other application level protocols for specific applications and it's usually easier to use those than trying to use transport protocols like TCP or UDP. For example streaming video is a really complex problem to solve but there are protocols like [RTP](https://en.wikipedia.org/wiki/Real-time_Transport_Protocol "Wikipedia on the Real-time Transport Protocol") that already solve or at least mitigate all the complications that it involves so using a library that implements RTP will be easier than trying to send video directly using TCP or UDP. From 676e4b636ca03b006ac13b30772c533c7838ec6a Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:50:56 +0200 Subject: [PATCH 62/80] mentioned URL style naming scheme for OSC --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 3a6bc8fc..088db7e4 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -115,7 +115,7 @@ In general use TCP if you need your messages to arrive no matter what, when loos ## OSC -[Open Sound Control (OSC)](http://opensoundcontrol.org/ "OSC website") is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done without worrying about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. +[Open Sound Control (OSC)](http://opensoundcontrol.org/ "OSC website") is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done with a URL style description of targets, so there no need to worry about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. From 8bbea788a2c13f5b90998aa12bce1ddf65cbb89b Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:51:24 +0200 Subject: [PATCH 63/80] two grammar fixes --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 088db7e4..2e954b76 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -115,7 +115,7 @@ In general use TCP if you need your messages to arrive no matter what, when loos ## OSC -[Open Sound Control (OSC)](http://opensoundcontrol.org/ "OSC website") is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done with a URL style description of targets, so there no need to worry about the underlying architecture of the sender and receiving machine. It's usually based on UDP so it has some of the same problems. +[Open Sound Control (OSC)](http://opensoundcontrol.org/ "OSC website") is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done with a URL style description of targets, so there is no need to worry about the underlying architecture of the sending and receiving machine. It's usually based on UDP so it has some of the same problems. It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. From 0580b07c02e83ef2bec8f0efcb6ac1b8916a0bb0 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 11:51:56 +0200 Subject: [PATCH 64/80] removed HEAD marker from previous merge --- chapters/network/chapter.md | 1 - 1 file changed, 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 2e954b76..a6af0869 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -98,7 +98,6 @@ udpManager.SendAll(message, message.size()); the other side will receive that message in one piece -- that is -- if it receives the datagram at all. -<<<<<<< HEAD As we've said before, UDP is not resistant to errors so the packet may not arrive. It may get corrupted and there's no way to recover it. If we send several packets they may arrive in a different order then they were sent. UDP also doesn't adjust for bandwidth, so if one side is sending faster than what the other side can receive, or even if it fills the local buffers while sending, some packets will get lost. What's worse, neither sender or receiver will receive any feedback that packets were lost. UDP might seem not useful but it has some advantages. First, it is fast! Since UDP doesn't require feedback (e.g. ACKs) and only minimal header information, there are less bytes to send. In many cases, this speed is more important than reliability. For example, if we are sending a packet every few frames with the state of our application we don't mind if one or two frames is lost because the destination will be updated with the next packet it receives. It's also really rare to loose UDP packets on a local network. Thus, if you need to send your packets very quickly (also known as low-latency) and you don't mind if a few packets are lost, UDP may be right for you. If your application requires confirmation that each and every byte arrived at its destination, you'll need to use TCP. From f4ea82e8dedb1ab1fc454015b3b22e61bf5f1c42 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 16:07:37 +0200 Subject: [PATCH 65/80] fixing typo --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index a6af0869..810848a4 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -20,7 +20,7 @@ TCP and UDP are 2 of the most used protocols to communicate through a network. I ### TCP -The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a manageable connection, UDP is more geared towards streams]** and resistant to errors, packet reordering and packet lose. Let's see what all that means. +The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a manageable connection, UDP is more geared towards streams]** and resistant to errors, packet reordering and packet loss. Let's see what all that means. To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send information (such as a large file) over the network, it is divided in smaller pieces of information called _packets_. Further, each segment of the network might support a different packet sizes, so those packets might be broken down into even smaller packets. So, ultimately a packet is just a small piece of the information we are trying to send plus some extra information called headers. Headers help keep track of things like packet size, transmission order and the source and destination of the packet. This division in packets is used among other things so it's easier to recover from errors. For example if we sent a large file in one giant packet, if some parts of it were corrupted during transmission we'd need to resend the full file again. Dividing it in packets containing a small piece of our data and some headers allows us to detect errors per packet so we only need to resend the corrupted packets instead of the whole thing. From 4c87f700b880fd6bdc24475d731f9970fb6a1796 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 16:08:02 +0200 Subject: [PATCH 66/80] fixing typo --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 810848a4..9ea9557d 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -114,7 +114,7 @@ In general use TCP if you need your messages to arrive no matter what, when loos ## OSC -[Open Sound Control (OSC)](http://opensoundcontrol.org/ "OSC website") is an application level protocol. It is of a higher level than UDP or TCP. It's main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done with a URL style description of targets, so there is no need to worry about the underlying architecture of the sending and receiving machine. It's usually based on UDP so it has some of the same problems. +[Open Sound Control (OSC)](http://opensoundcontrol.org/ "OSC website") is an application level protocol. It is of a higher level than UDP or TCP. Its main characteristic is that it allows to send types like int, float, string to specific endpoints. This is done with a URL style description of targets, so there is no need to worry about the underlying architecture of the sending and receiving machine. It's usually based on UDP so it has some of the same problems. It's usage in openFrameworks is really simple, so just check the examples in the examples/addons folder to know how it works. From a9aaf4e546a200b0e6bd845efca49fed419ad1d3 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Mon, 27 Apr 2015 16:08:58 +0200 Subject: [PATCH 67/80] fixing typo --- chapters/network/chapter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 9ea9557d..eaafaec1 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -44,7 +44,7 @@ TCP is also stream oriented. That means that we cannot send individual messages "Hello world!! this is an openFrameworks network message" -The application using TCP in the other side may receive it like: +The application using TCP on the other side may receive it like: "Hello w" "orld!" @@ -80,7 +80,7 @@ tcpClient.setMessageDelimiter(myDelimiter); ~~Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect to it. -There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has it's own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. +There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has its own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. While this is really practical, it means that if we have 2 computers behind NAT routers, it's impossible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP.~~ **[t: i moved this section to the beginning and expanded on it]** From b7c88c6acd495723242b9a9f3a33bf900397b0b4 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Tue, 28 Apr 2015 14:08:47 +0200 Subject: [PATCH 68/80] added network terms to glossary --- info/glossary.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/info/glossary.md b/info/glossary.md index 45f056d8..7019ba8a 100644 --- a/info/glossary.md +++ b/info/glossary.md @@ -18,12 +18,18 @@ ### IDE +### IP + ### Library ### Linker +### NAT + ### OpenGL +### OSC + ### Parameter ### pointer @@ -32,4 +38,8 @@ ### RGB color model +### TCP + ### Template + +### UDP \ No newline at end of file From d5eb88e5100d3646c978b1b196072f59a4d3eeaf Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:07:07 +0200 Subject: [PATCH 69/80] mention TCP + UDP by full name and link to wikipedia --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index eaafaec1..cf91137a 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -9,7 +9,7 @@ This chapter gives a brief overview over the things you need to know to use comp ## IP and NAT -In order to connect to a computer on the internet or your local network you need to be able to identify the machine. This is done by what is called an [IP address](https://en.wikipedia.org/wiki/IP_address "Wikipedia on IP addresses"). This is label is used as the source and destination address when sending data packets. These data packets encapsulate chunks of the information (like a file or a text string) you want to send (later more on that). In order to send data to a particular application, you also have to tell the machine where your data packets and the desired application meet. This meeting point is called a ["port"](https://en.wikipedia.org/wiki/Port_%28computer_networking%29 "Wikipedia on ports (for networking)"). For reference: The combination of an IP and a port is called a ["socket"](https://en.wikipedia.org/wiki/Network_socket "Wikipedia on network sockets"). IP only handles only the routing part of networking while other protocols handle other functionality. TCP and UDP for example handle the data transmission (see below). All this functionality is often talked about in terms of "layers" (of abstraction) and the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). +In order to connect to a computer on the internet or your local network you need to be able to identify the machine. This is done by what is called an [IP address](https://en.wikipedia.org/wiki/IP_address "Wikipedia on IP addresses"). This is label is used as the source and destination address when sending data packets. These data packets encapsulate chunks of the information (like a file or a text string) you want to send (later more on that). In order to send data to a particular application, you also have to tell the machine where your data packets and the desired application meet. This meeting point is called a ["port"](https://en.wikipedia.org/wiki/Port_%28computer_networking%29 "Wikipedia on ports (for networking)"). For reference: The combination of an IP and a port is called a ["socket"](https://en.wikipedia.org/wiki/Network_socket "Wikipedia on network sockets"). IP only handles only the routing part of networking while other protocols handle other functionality. The Transmission Control Protocol ([TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol "Wikipedia in the Transmission Control Protocol")) and the User Datagram Protocol ([UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol "Wikipedia on the User Datagram Protocol")) for example handle the data transmission (see below). All this functionality is often talked about in terms of "layers" (of abstraction) and the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). The IP protocol comes in two flavors: [IPv4](https://en.wikipedia.org/wiki/IPv4 "Wikipedia on IPv4") (still very common), where addresses look like "93.184.216.34" (so called ["dot-decima"](https://en.wikipedia.org/wiki/Dot-decimal_notation "Wikipedia on dot-decimal notation") or "dotted quad" notation) and [IPv6](https://en.wikipedia.org/wiki/IPv6 "Wikipedia on IPv6") (the current version), where addresses look like "2001:500:8c::53". An application ususally listens on a predetermined port and waits for data to arrive. For some applications (like webservers) these are (informally) [standardized](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml "IANA list of port numbers") (like ports 80 and 443), others (like maybe yours) just picks a free port number. As long as you do not pick one already in use, this is not (too much) of a problem. No two processes can use ("bind to") the same port number (and protocol), so there is only one application listening on port 80 for TCP connections (but another one might listen on port 80 for UDP connections). This is usually enforced by the operating system. The combination of IP and port is written as "93.184.216.34:80" in the case of IPv4 and "[2001:500:8c::53]:80" in the case of IPv6. Since people are bad at remembering long strings of random looking numbers and characters, there is a system in place to map [domain names](https://en.wikipedia.org/wiki/Domain_name "Wikipedia on domain names") into IP addresses. It is called [Domain Name System or DNS](https://en.wikipedia.org/wiki/Domain_Name_System "Wikipedia on the Domain Name System"). Here the IP/port pair (or socket) is notated as "[example.net]:80". Not all IP addresses can be reached. There is a [range of IPv4 addressed](https://tools.ietf.org/html/rfc1918 "RFC 1918: Address Allocation for Private Internets") and a [range of IPv6 addresses](https://tools.ietf.org/html/rfc4193 "RFC 4193: Unique Local IPv6 Unicast Addresses") which are called "private". That means that your [router](https://en.wikipedia.org/wiki/Router_%28computing%29 "Wikipedia on routers") will not pass on packets coming from these ranges into the internet. Your computer at home probably has a private IPv4 address of "192.168.x.x" or "10.x.x.x". That means that machines in your local network can talk to it, but no one from the outside. Your router as a public IP address and translates the packets with your requests to outside resources (e.g. when you surf the web). The router does so called "Network Address Translation (NAT)"](https://en.wikipedia.org/wiki/Network_address_translation "Wikipedia on Network Address Translation"). It takes addresses from one address range (your private one) and translates them to another one (the public range) back and forth (for an established connection). Since your ["Internet Service Provider (ISP)"](https://en.wikipedia.org/wiki/Internet_service_provider "Wikipedia on Internet Service Providers") assigns the public IP to your router, you have litte control over it. This in itself is quite useful from a management perspective, but it also means that two devices behind NAT usually can not talk to each other (since they are ususally not part of DNS and so called ["port forwarding"](https://en.wikipedia.org/wiki/Port_forwarding "Wikipedia on port forwarding") is not enabled by default on your router). To get around this you either have to enable port forwarding and know the IP of your destination router or use addons like [ofxNice](https://github.com/arturoc/ofxNice) that allows you to do NAT transversal (but it will only work for UDP). From 0d8bb04feec8fd1ffc656690e60f6c81d917e06f Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:30:28 +0200 Subject: [PATCH 70/80] removed TCP annotation --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index cf91137a..6690a8c3 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -20,7 +20,7 @@ TCP and UDP are 2 of the most used protocols to communicate through a network. I ### TCP -The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a protocol ~~based on a connection, stream based~~ connection oriented **[t: TCP tries to establish a manageable connection, UDP is more geared towards streams]** and resistant to errors, packet reordering and packet loss. Let's see what all that means. +The **Transmission Control Protocol** is without doubt the most used network protocol on the Internet. It is a connection oriented protocol and is resistant to errors, packet reordering and packet loss. Let's see what all that means. To understand all that we might need to know a bit about how a TCP/IP network works. First of all we need to know that when we send information (such as a large file) over the network, it is divided in smaller pieces of information called _packets_. Further, each segment of the network might support a different packet sizes, so those packets might be broken down into even smaller packets. So, ultimately a packet is just a small piece of the information we are trying to send plus some extra information called headers. Headers help keep track of things like packet size, transmission order and the source and destination of the packet. This division in packets is used among other things so it's easier to recover from errors. For example if we sent a large file in one giant packet, if some parts of it were corrupted during transmission we'd need to resend the full file again. Dividing it in packets containing a small piece of our data and some headers allows us to detect errors per packet so we only need to resend the corrupted packets instead of the whole thing. From 6c213446dee1a632fc0db499d689f5d5dfaad56e Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:31:43 +0200 Subject: [PATCH 71/80] removed ACK annotation --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 6690a8c3..494eafd4 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -34,7 +34,7 @@ TCP is able to solve all of those problems. When TCP sends packets it numbers th When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. -This ~~ACKs~~signalling **[t: TCP uses sliding windows and congestion control to regulate the flow. The ACK only acknowledges the reception of a packet]** also allows to regulate the speed with which packets are sent. If the client has less bandwidth than the server, the server can slow down sending packets until it arrives at a speed at which the client can receive them. +This internal signalling also allows to regulate the speed with which packets are sent. If the client has less bandwidth than the server, the server can slow down sending packets until it arrives at a speed at which the client can receive them. As we see, using a TCP connection ensures that everything we send is received correctly on the other side. From c1af451ce33e208fa33d479bb76d789cb8b5db33 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:32:32 +0200 Subject: [PATCH 72/80] removed annotation on moved section --- chapters/network/chapter.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 494eafd4..d6a4862a 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -78,12 +78,6 @@ If the protocol you are working with uses TCP and a delimiter, chances are you m tcpClient.setMessageDelimiter(myDelimiter); ``` -~~Something important that you might know already: in order to connect applications through a TCP/IP transport network protocol, you usually need, an IP address and a port, the IP address is specific to each machine, the port to each application. So with an IP/port pair we can define an application running in a specific address along all Internet, almost. For example an application that is running a web server usually runs on port 80, if the machine is being executed in has the IP 15.6.8.2, 15.6.8.2:80 defines that web server among any other application running in any other machine in all the Internet. So if we want to connect two machines, usually all we need to know is the IP and port of the application running in the server and use it in the client to connect to it. - -There's an exception though. In most internal networks, like your home network for example, there's a router that connects the machines in that network to the Internet. These routers usually do something called NAT: Network Address Translation. NAT was invented because the IPv4 protocol has a limited number of IP addresses. Internally, the network uses a reserved range of addresses: 192.168.x.x/24 or 10.x.x.x/32, which are addresses that won't be found directly on the internet. When we try to connect to an external address it acts as a kind of proxy between your computer and the server that we want to connect. The router has its own external address, and when it receives a response it translates the address and port in which it has received it to an internal one, the one from our computer and sends the packets back to us. - -While this is really practical, it means that if we have 2 computers behind NAT routers, it's impossible to open a connection between them (in principle) . There's ways to configure a router to send any packet sent to a specific port to the same internal address. There's also libraries like [ofxNice](https://github.com/arturoc/ofxNice) that allow you to do NAT transversal, but that will only work using UDP.~~ **[t: i moved this section to the beginning and expanded on it]** - ### UDP From 9cd2424ae8b9449efb17b03566fa261efd4881cf Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:34:04 +0200 Subject: [PATCH 73/80] removed UDP annotation --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index d6a4862a..bbb0330c 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -81,7 +81,7 @@ tcpClient.setMessageDelimiter(myDelimiter); ### UDP -UDP or **User Datagram Protocol**, is a ~~non-connection datagram oriented, non error resistant protocol~~ protocol oriented towards single individual messages and can not easily recover from transmission errors **[t: rephrasing for easier understanding & to avoid negations]**. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there is a process listening on that machine and that port it will receive the message. +UDP or **User Datagram Protocol**, is a protocol oriented towards single individual messages and can not easily recover from transmission errors. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there is a process listening on that machine and that port it will receive the message. ~~Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side.~~ The packet size supported by the networks along the transmission path is central to datagram oriented protocols like UDP. Each message has to be smaller (or equal) to the [Maximum Transmission Unit](https://en.wikipedia.org/wiki/Maximum_transmission_unit "Wikipedia on maximum transmission unit") of a connection/path in order to be passed on. If a packet is larger than the MTU it (theoretically) should be broken up, but since UDP (unlike TCP) has no information on packet order or (re-)assembly, the packet just gets dropped. **[t: rephrased & extended for better understanding]** In openFrameworks, if we do: From 461962d7e0d227abefbe45eb38eda18d9a992da7 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:35:39 +0200 Subject: [PATCH 74/80] removed MTU annotation --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index bbb0330c..87bdcc95 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -83,7 +83,7 @@ tcpClient.setMessageDelimiter(myDelimiter); UDP or **User Datagram Protocol**, is a protocol oriented towards single individual messages and can not easily recover from transmission errors. It is more or less the total opposite to TCP. We don't need to establish a connection, instead we just send messages to a specific address and port. As long as there is a process listening on that machine and that port it will receive the message. -~~Datagram oriented means that whatever we send, that fits in the packet size supported by the network, by all the sub-networks in the path from one computer to another, will arrive in one piece on the other side.~~ The packet size supported by the networks along the transmission path is central to datagram oriented protocols like UDP. Each message has to be smaller (or equal) to the [Maximum Transmission Unit](https://en.wikipedia.org/wiki/Maximum_transmission_unit "Wikipedia on maximum transmission unit") of a connection/path in order to be passed on. If a packet is larger than the MTU it (theoretically) should be broken up, but since UDP (unlike TCP) has no information on packet order or (re-)assembly, the packet just gets dropped. **[t: rephrased & extended for better understanding]** In openFrameworks, if we do: +The packet size supported by the networks along the transmission path is central to datagram oriented protocols like UDP. Each message has to be smaller (or equal) to the [Maximum Transmission Unit](https://en.wikipedia.org/wiki/Maximum_transmission_unit "Wikipedia on maximum transmission unit") of a connection/path in order to be passed on. If a packet is larger than the MTU it (theoretically) should be broken up, but since UDP (unlike TCP) has no information on packet order or (re-)assembly, the packet just gets dropped. In openFrameworks, if we do: ```cpp string message = "Hello world!! this is an openFrameworks network message"; From bb2f17e3c4505c2989fc1f07ca25699bd46510ed Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:37:31 +0200 Subject: [PATCH 75/80] separated authors --- chapters/network/chapter.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 87bdcc95..b6ee3ea9 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -2,7 +2,9 @@ *by [Arturo Castro](http://arturocastro.net)* + *extensions by tpltnt* + *corrections by Brannon Dorsey* This chapter gives a brief overview over the things you need to know to use computer networks with openFrameworks. Do not be afraid if you do not understand all the concepts. The idea is more to give you a basic understanding, some terminology and references so you can explore this topic and go deeper when you want (or need) to. From c4fc3c66e627796a0ba87a27df7bed348fcdeb65 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:38:42 +0200 Subject: [PATCH 76/80] fixed markdown typo --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index b6ee3ea9..e09274c7 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -32,7 +32,7 @@ Another problem is that packets might get corrupted on their way to the destinat With all that let's say we send packets ABCD in that order, it might be that at the other end we get something like GCB: packet A got corrupted and turned into G, packets B and C arrived ok but in the wrong order, and packet D was totally lost. -TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer receives them. It also adds something called a [CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check "Wikipedia on Cyclic Redundancy Check" to each packet that allows the other computer to know if that packet is corrupt. +TCP is able to solve all of those problems. When TCP sends packets it numbers them so that they can be correctly ordered when the other computer receives them. It also adds something called a [CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check "Wikipedia on Cyclic Redundancy Check") to each packet that allows the other computer to know if that packet is corrupt. When the destination receives a packet and that packet is correct, it sends a confirmation, also called an ACK. If after some time the sender hasn't received that confirmation, it sends the packet again. That solves the problem of corrupted and lost packets. From bf59ebf5468cc1990b1f6417b954b392d3dbe533 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:39:31 +0200 Subject: [PATCH 77/80] fixed markdown typo --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index e09274c7..87b79f7e 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -13,7 +13,7 @@ This chapter gives a brief overview over the things you need to know to use comp In order to connect to a computer on the internet or your local network you need to be able to identify the machine. This is done by what is called an [IP address](https://en.wikipedia.org/wiki/IP_address "Wikipedia on IP addresses"). This is label is used as the source and destination address when sending data packets. These data packets encapsulate chunks of the information (like a file or a text string) you want to send (later more on that). In order to send data to a particular application, you also have to tell the machine where your data packets and the desired application meet. This meeting point is called a ["port"](https://en.wikipedia.org/wiki/Port_%28computer_networking%29 "Wikipedia on ports (for networking)"). For reference: The combination of an IP and a port is called a ["socket"](https://en.wikipedia.org/wiki/Network_socket "Wikipedia on network sockets"). IP only handles only the routing part of networking while other protocols handle other functionality. The Transmission Control Protocol ([TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol "Wikipedia in the Transmission Control Protocol")) and the User Datagram Protocol ([UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol "Wikipedia on the User Datagram Protocol")) for example handle the data transmission (see below). All this functionality is often talked about in terms of "layers" (of abstraction) and the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). The IP protocol comes in two flavors: [IPv4](https://en.wikipedia.org/wiki/IPv4 "Wikipedia on IPv4") (still very common), where addresses look like "93.184.216.34" (so called ["dot-decima"](https://en.wikipedia.org/wiki/Dot-decimal_notation "Wikipedia on dot-decimal notation") or "dotted quad" notation) and [IPv6](https://en.wikipedia.org/wiki/IPv6 "Wikipedia on IPv6") (the current version), where addresses look like "2001:500:8c::53". An application ususally listens on a predetermined port and waits for data to arrive. For some applications (like webservers) these are (informally) [standardized](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml "IANA list of port numbers") (like ports 80 and 443), others (like maybe yours) just picks a free port number. As long as you do not pick one already in use, this is not (too much) of a problem. No two processes can use ("bind to") the same port number (and protocol), so there is only one application listening on port 80 for TCP connections (but another one might listen on port 80 for UDP connections). This is usually enforced by the operating system. The combination of IP and port is written as "93.184.216.34:80" in the case of IPv4 and "[2001:500:8c::53]:80" in the case of IPv6. Since people are bad at remembering long strings of random looking numbers and characters, there is a system in place to map [domain names](https://en.wikipedia.org/wiki/Domain_name "Wikipedia on domain names") into IP addresses. It is called [Domain Name System or DNS](https://en.wikipedia.org/wiki/Domain_Name_System "Wikipedia on the Domain Name System"). Here the IP/port pair (or socket) is notated as "[example.net]:80". -Not all IP addresses can be reached. There is a [range of IPv4 addressed](https://tools.ietf.org/html/rfc1918 "RFC 1918: Address Allocation for Private Internets") and a [range of IPv6 addresses](https://tools.ietf.org/html/rfc4193 "RFC 4193: Unique Local IPv6 Unicast Addresses") which are called "private". That means that your [router](https://en.wikipedia.org/wiki/Router_%28computing%29 "Wikipedia on routers") will not pass on packets coming from these ranges into the internet. Your computer at home probably has a private IPv4 address of "192.168.x.x" or "10.x.x.x". That means that machines in your local network can talk to it, but no one from the outside. Your router as a public IP address and translates the packets with your requests to outside resources (e.g. when you surf the web). The router does so called "Network Address Translation (NAT)"](https://en.wikipedia.org/wiki/Network_address_translation "Wikipedia on Network Address Translation"). It takes addresses from one address range (your private one) and translates them to another one (the public range) back and forth (for an established connection). Since your ["Internet Service Provider (ISP)"](https://en.wikipedia.org/wiki/Internet_service_provider "Wikipedia on Internet Service Providers") assigns the public IP to your router, you have litte control over it. This in itself is quite useful from a management perspective, but it also means that two devices behind NAT usually can not talk to each other (since they are ususally not part of DNS and so called ["port forwarding"](https://en.wikipedia.org/wiki/Port_forwarding "Wikipedia on port forwarding") is not enabled by default on your router). To get around this you either have to enable port forwarding and know the IP of your destination router or use addons like [ofxNice](https://github.com/arturoc/ofxNice) that allows you to do NAT transversal (but it will only work for UDP). +Not all IP addresses can be reached. There is a [range of IPv4 addressed](https://tools.ietf.org/html/rfc1918 "RFC 1918: Address Allocation for Private Internets") and a [range of IPv6 addresses](https://tools.ietf.org/html/rfc4193 "RFC 4193: Unique Local IPv6 Unicast Addresses") which are called "private". That means that your [router](https://en.wikipedia.org/wiki/Router_%28computing%29 "Wikipedia on routers") will not pass on packets coming from these ranges into the internet. Your computer at home probably has a private IPv4 address of "192.168.x.x" or "10.x.x.x". That means that machines in your local network can talk to it, but no one from the outside. Your router as a public IP address and translates the packets with your requests to outside resources (e.g. when you surf the web). The router does so called ["Network Address Translation (NAT)"](https://en.wikipedia.org/wiki/Network_address_translation "Wikipedia on Network Address Translation"). It takes addresses from one address range (your private one) and translates them to another one (the public range) back and forth (for an established connection). Since your ["Internet Service Provider (ISP)"](https://en.wikipedia.org/wiki/Internet_service_provider "Wikipedia on Internet Service Providers") assigns the public IP to your router, you have litte control over it. This in itself is quite useful from a management perspective, but it also means that two devices behind NAT usually can not talk to each other (since they are ususally not part of DNS and so called ["port forwarding"](https://en.wikipedia.org/wiki/Port_forwarding "Wikipedia on port forwarding") is not enabled by default on your router). To get around this you either have to enable port forwarding and know the IP of your destination router or use addons like [ofxNice](https://github.com/arturoc/ofxNice) that allows you to do NAT transversal (but it will only work for UDP). ## TCP vs. UDP From 776daafe71feeb7b4efa853a6f048158854c6631 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:40:47 +0200 Subject: [PATCH 78/80] fixed quotation marks --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index 87b79f7e..b8a3feab 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -13,7 +13,7 @@ This chapter gives a brief overview over the things you need to know to use comp In order to connect to a computer on the internet or your local network you need to be able to identify the machine. This is done by what is called an [IP address](https://en.wikipedia.org/wiki/IP_address "Wikipedia on IP addresses"). This is label is used as the source and destination address when sending data packets. These data packets encapsulate chunks of the information (like a file or a text string) you want to send (later more on that). In order to send data to a particular application, you also have to tell the machine where your data packets and the desired application meet. This meeting point is called a ["port"](https://en.wikipedia.org/wiki/Port_%28computer_networking%29 "Wikipedia on ports (for networking)"). For reference: The combination of an IP and a port is called a ["socket"](https://en.wikipedia.org/wiki/Network_socket "Wikipedia on network sockets"). IP only handles only the routing part of networking while other protocols handle other functionality. The Transmission Control Protocol ([TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol "Wikipedia in the Transmission Control Protocol")) and the User Datagram Protocol ([UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol "Wikipedia on the User Datagram Protocol")) for example handle the data transmission (see below). All this functionality is often talked about in terms of "layers" (of abstraction) and the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). The IP protocol comes in two flavors: [IPv4](https://en.wikipedia.org/wiki/IPv4 "Wikipedia on IPv4") (still very common), where addresses look like "93.184.216.34" (so called ["dot-decima"](https://en.wikipedia.org/wiki/Dot-decimal_notation "Wikipedia on dot-decimal notation") or "dotted quad" notation) and [IPv6](https://en.wikipedia.org/wiki/IPv6 "Wikipedia on IPv6") (the current version), where addresses look like "2001:500:8c::53". An application ususally listens on a predetermined port and waits for data to arrive. For some applications (like webservers) these are (informally) [standardized](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml "IANA list of port numbers") (like ports 80 and 443), others (like maybe yours) just picks a free port number. As long as you do not pick one already in use, this is not (too much) of a problem. No two processes can use ("bind to") the same port number (and protocol), so there is only one application listening on port 80 for TCP connections (but another one might listen on port 80 for UDP connections). This is usually enforced by the operating system. The combination of IP and port is written as "93.184.216.34:80" in the case of IPv4 and "[2001:500:8c::53]:80" in the case of IPv6. Since people are bad at remembering long strings of random looking numbers and characters, there is a system in place to map [domain names](https://en.wikipedia.org/wiki/Domain_name "Wikipedia on domain names") into IP addresses. It is called [Domain Name System or DNS](https://en.wikipedia.org/wiki/Domain_Name_System "Wikipedia on the Domain Name System"). Here the IP/port pair (or socket) is notated as "[example.net]:80". -Not all IP addresses can be reached. There is a [range of IPv4 addressed](https://tools.ietf.org/html/rfc1918 "RFC 1918: Address Allocation for Private Internets") and a [range of IPv6 addresses](https://tools.ietf.org/html/rfc4193 "RFC 4193: Unique Local IPv6 Unicast Addresses") which are called "private". That means that your [router](https://en.wikipedia.org/wiki/Router_%28computing%29 "Wikipedia on routers") will not pass on packets coming from these ranges into the internet. Your computer at home probably has a private IPv4 address of "192.168.x.x" or "10.x.x.x". That means that machines in your local network can talk to it, but no one from the outside. Your router as a public IP address and translates the packets with your requests to outside resources (e.g. when you surf the web). The router does so called ["Network Address Translation (NAT)"](https://en.wikipedia.org/wiki/Network_address_translation "Wikipedia on Network Address Translation"). It takes addresses from one address range (your private one) and translates them to another one (the public range) back and forth (for an established connection). Since your ["Internet Service Provider (ISP)"](https://en.wikipedia.org/wiki/Internet_service_provider "Wikipedia on Internet Service Providers") assigns the public IP to your router, you have litte control over it. This in itself is quite useful from a management perspective, but it also means that two devices behind NAT usually can not talk to each other (since they are ususally not part of DNS and so called ["port forwarding"](https://en.wikipedia.org/wiki/Port_forwarding "Wikipedia on port forwarding") is not enabled by default on your router). To get around this you either have to enable port forwarding and know the IP of your destination router or use addons like [ofxNice](https://github.com/arturoc/ofxNice) that allows you to do NAT transversal (but it will only work for UDP). +Not all IP addresses can be reached. There is a [range of IPv4 addressed](https://tools.ietf.org/html/rfc1918 "RFC 1918: Address Allocation for Private Internets") and a [range of IPv6 addresses](https://tools.ietf.org/html/rfc4193 "RFC 4193: Unique Local IPv6 Unicast Addresses") which are called "private". That means that your [router](https://en.wikipedia.org/wiki/Router_%28computing%29 "Wikipedia on routers") will not pass on packets coming from these ranges into the internet. Your computer at home probably has a private IPv4 address of "192.168.x.x" or "10.x.x.x". That means that machines in your local network can talk to it, but no one from the outside. Your router as a public IP address and translates the packets with your requests to outside resources (e.g. when you surf the web). The router does so called [Network Address Translation (NAT)](https://en.wikipedia.org/wiki/Network_address_translation "Wikipedia on Network Address Translation"). It takes addresses from one address range (your private one) and translates them to another one (the public range) back and forth (for an established connection). Since your [Internet Service Provider (ISP)](https://en.wikipedia.org/wiki/Internet_service_provider "Wikipedia on Internet Service Providers") assigns the public IP to your router, you have litte control over it. This in itself is quite useful from a management perspective, but it also means that two devices behind NAT usually can not talk to each other (since they are ususally not part of DNS and so called ["port forwarding"](https://en.wikipedia.org/wiki/Port_forwarding "Wikipedia on port forwarding") is not enabled by default on your router). To get around this you either have to enable port forwarding and know the IP of your destination router or use addons like [ofxNice](https://github.com/arturoc/ofxNice) that allows you to do NAT transversal (but it will only work for UDP). ## TCP vs. UDP From 6cdf446da210002b78e487f0554f7f70ea733e66 Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:45:54 +0200 Subject: [PATCH 79/80] HTTP, FTP, OSC named and linked to wikipedia --- chapters/network/chapter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/network/chapter.md b/chapters/network/chapter.md index b8a3feab..202a0948 100644 --- a/chapters/network/chapter.md +++ b/chapters/network/chapter.md @@ -18,7 +18,7 @@ Not all IP addresses can be reached. There is a [range of IPv4 addressed](https: ## TCP vs. UDP -TCP and UDP are 2 of the most used protocols to communicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). TCP and UDP belong to layer 4, the transport layer, and are usually the most used in oF along with protocols from layer 7, the application protocol, like HTTP, FTP or OSC that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. +TCP and UDP are 2 of the most used protocols to communicate through a network. Indeed TCP is so common that the suite of protocols on which internet is based is usually called TCP/IP. The network protocols are classified in layers by something called the [OSI model](https://en.wikipedia.org/wiki/OSI_model "Wikipedia on the OSI model"). TCP and UDP belong to layer 4, the transport layer, and are usually the most used in oF along with protocols from layer 7, the application protocol, like the Hypertext Transfer Protocol ([HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol "Wikipedia on the Hypertext Transfer Protocol")), the File Transfer Protocol ([FTP](https://en.wikipedia.org/wiki/File_Transfer_Protocol "Wikipedia on the File Transfer Protocol")) or Open Sound Control ([OSC](https://en.wikipedia.org/wiki/Open_Sound_Control "Wikipedia on Open Sound Control")) that actually work on top of the other layers, for example HTTP and FTP on top of TCP and OSC usually on top of UDP. ### TCP From c62c1612888b20ff60d129c562e48d970845f2fc Mon Sep 17 00:00:00 2001 From: tpltnt Date: Thu, 22 Oct 2015 16:49:34 +0200 Subject: [PATCH 80/80] added DNS & FTP to glossary --- info/glossary.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/info/glossary.md b/info/glossary.md index 476bdcfc..cbe334bd 100644 --- a/info/glossary.md +++ b/info/glossary.md @@ -14,6 +14,10 @@ ### Coordinate System +### Domain Name System (DNS) + +### File Transfer Protocol (FTP) + ### Function ### IDE