├── .gitignore ├── Images ├── Layers.png ├── FEUP_Logo.png ├── FreeSpace.png └── Modulation.png ├── Project1 ├── bin │ ├── main │ └── cable ├── Report.pdf ├── cable │ ├── cable │ └── cable.c ├── penguin.gif ├── Makefile ├── main.c ├── include │ ├── application_layer.h │ └── link_layer.h ├── README.md └── src │ ├── application_layer.c │ └── link_layer.c ├── Project2 ├── download ├── img │ ├── Exp1.png │ ├── Exp2a.png │ ├── Exp2b.png │ ├── Exp3a.png │ ├── Exp3b.png │ ├── Exp4a.png │ ├── Exp4b.png │ ├── Exp4c.png │ ├── Exp4d.png │ ├── Exp5.png │ ├── Exp6a.png │ ├── Exp6b.png │ ├── Exp6c.png │ └── Exp6d.png ├── RCOM Project 2.pdf ├── docs │ ├── Exp1.pcapng │ ├── exp5T3.pcapng │ ├── exp1topic3T3.pcapng │ ├── exp2topic6T3.pcapng │ ├── exp3topic7T3.pcapng │ ├── exp4topic3T3.pcapng │ ├── exp4topic4T2.pcapng │ ├── exp2topic9v1T2.pcapng │ ├── exp2topic9v1T3.pcapng │ ├── exp2topic9v1T4.pcapng │ ├── exp2topic9v2T2.pcapng │ ├── exp2topic9v2T3.pcapng │ ├── exp2topic9v2T4.pcapng │ ├── exp3topic11eth0T4.pcapng │ └── exp3topic11eth1T4.pcapng ├── Makefile ├── network │ ├── 7 - Configure Internet.md │ ├── README.md │ ├── 5 - DNS.md │ ├── 6 - TCP connections.md │ ├── 2 - Implement two bridges in a switch.md │ ├── 1 - Configure an IP Network.md │ ├── 3 - Configure a Router in Linux.md │ └── 4 - Configure a Commercial Router and Implement NAT.md ├── README.md ├── pipe.txt ├── include │ └── download.h └── src │ └── download.c ├── README.md └── Notes ├── 8 - Routing.md ├── 1 - Introduction.md ├── 9 - Application Layer.md ├── 2 - Physical Layer.md ├── 7 - Transport Layer.md ├── 4 - Delay Models.md ├── 5 - MAC.md ├── 6 - Network Layer.md ├── 3 - Data Link Layer.md └── Exam.md /.gitignore: -------------------------------------------------------------------------------- 1 | .idea 2 | .DS_Store 3 | *.o -------------------------------------------------------------------------------- /Images/Layers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Images/Layers.png -------------------------------------------------------------------------------- /Project1/bin/main: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project1/bin/main -------------------------------------------------------------------------------- /Project2/download: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/download -------------------------------------------------------------------------------- /Project1/Report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project1/Report.pdf -------------------------------------------------------------------------------- /Project1/bin/cable: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project1/bin/cable -------------------------------------------------------------------------------- /Images/FEUP_Logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Images/FEUP_Logo.png -------------------------------------------------------------------------------- /Images/FreeSpace.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Images/FreeSpace.png -------------------------------------------------------------------------------- /Images/Modulation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Images/Modulation.png -------------------------------------------------------------------------------- /Project1/cable/cable: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project1/cable/cable -------------------------------------------------------------------------------- /Project1/penguin.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project1/penguin.gif -------------------------------------------------------------------------------- /Project2/img/Exp1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp1.png -------------------------------------------------------------------------------- /Project2/img/Exp2a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp2a.png -------------------------------------------------------------------------------- /Project2/img/Exp2b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp2b.png -------------------------------------------------------------------------------- /Project2/img/Exp3a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp3a.png -------------------------------------------------------------------------------- /Project2/img/Exp3b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp3b.png -------------------------------------------------------------------------------- /Project2/img/Exp4a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp4a.png -------------------------------------------------------------------------------- /Project2/img/Exp4b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp4b.png -------------------------------------------------------------------------------- /Project2/img/Exp4c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp4c.png -------------------------------------------------------------------------------- /Project2/img/Exp4d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp4d.png -------------------------------------------------------------------------------- /Project2/img/Exp5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp5.png -------------------------------------------------------------------------------- /Project2/img/Exp6a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp6a.png -------------------------------------------------------------------------------- /Project2/img/Exp6b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp6b.png -------------------------------------------------------------------------------- /Project2/img/Exp6c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp6c.png -------------------------------------------------------------------------------- /Project2/img/Exp6d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/img/Exp6d.png -------------------------------------------------------------------------------- /Project2/RCOM Project 2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/RCOM Project 2.pdf -------------------------------------------------------------------------------- /Project2/docs/Exp1.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/Exp1.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp5T3.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp5T3.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp1topic3T3.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp1topic3T3.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp2topic6T3.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp2topic6T3.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp3topic7T3.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp3topic7T3.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp4topic3T3.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp4topic3T3.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp4topic4T2.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp4topic4T2.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp2topic9v1T2.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp2topic9v1T2.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp2topic9v1T3.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp2topic9v1T3.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp2topic9v1T4.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp2topic9v1T4.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp2topic9v2T2.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp2topic9v2T2.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp2topic9v2T3.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp2topic9v2T3.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp2topic9v2T4.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp2topic9v2T4.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp3topic11eth0T4.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp3topic11eth0T4.pcapng -------------------------------------------------------------------------------- /Project2/docs/exp3topic11eth1T4.pcapng: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fabio-A-Sa/Y3S1-RedesComputadores/HEAD/Project2/docs/exp3topic11eth1T4.pcapng -------------------------------------------------------------------------------- /Project2/Makefile: -------------------------------------------------------------------------------- 1 | CC = gcc 2 | CFLAGS = -Wall 3 | 4 | SRC = src/ 5 | INCLUDE = include/ 6 | BIN = bin/ 7 | 8 | .PHONY: downloader 9 | downloader: $(SRC)/download.c 10 | $(CC) $(CFLAGS) -o download $^ 11 | 12 | .PHONY: clean 13 | clean: 14 | rm -rf download -------------------------------------------------------------------------------- /Project2/network/7 - Configure Internet.md: -------------------------------------------------------------------------------- 1 | # 2.7 Configure Internet 2 | 3 | ## Steps 4 | 5 | 1. Conectar 5.1 com o E0 do Tux53; 6 | 2. Em Tux53 executar os seguintes comandos: 7 | 8 | ```bash 9 | $ ifconfig eth0 172.16.1.53/24 10 | $ route add default gw 172.16.1.254 11 | ``` -------------------------------------------------------------------------------- /Project2/network/README.md: -------------------------------------------------------------------------------- 1 | # Configuration and Study of a Network 2 | 3 | ## Apontamentos 4 | 5 | - As portas EX são as portas de rede; 6 | - As portas SX conectam-se diretamente à porta série do Tux X; 7 | - O router é o dispositivo preto; 8 | - O switch é o dispositivo branco; 9 | - Nunca desligar os cabos de X.11 e X.12 na régua de cima. Estes garantem a internet dos computadores mais próximos do corredor; 10 | - Não usar nas experiências o Tux 1; 11 | - Para alternar entre computadores, clicar duas vezes em "Scroll Lock", seguido do número do computador e "Enter"; -------------------------------------------------------------------------------- /Project2/network/5 - DNS.md: -------------------------------------------------------------------------------- 1 | # 2.5 - DNS 2 | 3 | >## Steps 4 | > 5 | >1. Em todos os Tuxs, adicionar a seguinte linha ao ficheiro /etc/resolv.conf 6 | > 7 | >```note 8 | >nameserver 172.16.1.1 9 | >``` 10 | >2. Em todos os Tux, fazer ping do google para verificar se podem ser usados nomes como host 11 | > 12 | >```bash 13 | >ping google.com 14 | >``` 15 | 16 | ## Questions 17 | 18 | How to configure the DNS service at a host? 19 | 20 | ```note 21 | O DNS pode ser configurado adicionando a linha "nameserver " no ficheiro /etc/resolv.conf de todos os Tuxs presentes. 22 | ``` 23 | 24 | What packets are exchanged by DNS and what information is transported? 25 | 26 | ```note 27 | Os pacotes transportados pela rede são inicialmente do tipo DNS, para que o router identifique e traduza o endereço IP de destino. 28 | ``` 29 | 30 | ![DNS Packets](../img/Exp5.png) 31 | -------------------------------------------------------------------------------- /Project2/README.md: -------------------------------------------------------------------------------- 1 | # RCOM Project 2 2 | 3 | ## 1. FTP Downloader 4 | 5 | ```bash 6 | $ make clean 7 | $ make downloader 8 | $ download ftp://[:@]/ 9 | ``` 10 | 11 | ## 2. Configuration and Study of a Network 12 | 13 | - [Configure an IP Network](./network/1%20-%20Configure%20an%20IP%20Network.md) 14 | - [Implement two bridges in a switch](./network/2%20-%20Implement%20two%20bridges%20in%20a%20switch.md) 15 | - [Configure a Router in Linux](./network/3%20-%20Configure%20a%20Router%20in%20Linux.md) 16 | - [Configure a Commercial Router and Implement NAT](./network/4%20-%20Configure%20a%20Commercial%20Router%20and%20Implement%20NAT.md) 17 | - [DNS](./network/5%20-%20DNS.md) 18 | - [TCP connections](./network/6%20-%20TCP%20connections.md) 19 | - [Configure Internet](./network/7%20-%20Configure%20Internet.md) 20 | 21 | ## Members 22 | 23 | ##### 3LEIC05 Group 05 24 | 25 | - Fábio Araújo de Sá (up202007658@fe.up.pt) 26 | - Lourenço Alexandre Correia Gonçalves (up202004816@fe.up.pt) -------------------------------------------------------------------------------- /Project1/Makefile: -------------------------------------------------------------------------------- 1 | # Makefile to build the project 2 | # NOTE: This file must not be changed. 3 | 4 | # Parameters 5 | CC = gcc 6 | CFLAGS = -Wall 7 | 8 | SRC = src/ 9 | INCLUDE = include/ 10 | BIN = bin/ 11 | CABLE_DIR = cable/ 12 | 13 | TX_SERIAL_PORT = /dev/ttyS10 14 | RX_SERIAL_PORT = /dev/ttyS11 15 | 16 | TX_FILE = penguin.gif 17 | RX_FILE = penguin-received.gif 18 | 19 | # Targets 20 | .PHONY: all 21 | all: $(BIN)/main $(BIN)/cable 22 | 23 | $(BIN)/main: main.c $(SRC)/*.c 24 | $(CC) $(CFLAGS) -o $@ $^ -I$(INCLUDE) -lm 25 | 26 | $(BIN)/cable: $(CABLE_DIR)/cable.c 27 | $(CC) $(CFLAGS) -o $@ $^ 28 | 29 | .PHONY: run_tx 30 | run_tx: $(BIN)/main 31 | ./$(BIN)/main $(TX_SERIAL_PORT) tx $(TX_FILE) -lm 32 | 33 | .PHONY: run_rx 34 | run_rx: $(BIN)/main 35 | ./$(BIN)/main $(RX_SERIAL_PORT) rx $(RX_FILE) -lm 36 | 37 | .PHONY: run_cable 38 | run_cable: $(BIN)/cable 39 | ./$(BIN)/cable 40 | 41 | .PHONY: check_files 42 | check_files: 43 | diff -s $(TX_FILE) $(RX_FILE) || exit 0 44 | 45 | .PHONY: clean 46 | clean: 47 | rm -f $(BIN)/main 48 | rm -f $(BIN)/cable 49 | rm -f $(RX_FILE) 50 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Redes de Computadores (RC) - Year 3, Semester 1 (Y3S1) 2 | 3 | This repository contains all the exercises and assessments of the UC Redes de Computadores, taught by [Manuel Pereira Ricardo](https://sigarra.up.pt/feup/pt/func_geral.formview?p_codigo=236891) and [Filipe Borges Teixeira](https://sigarra.up.pt/feup/pt/func_geral.formview?p_codigo=553729) at [Integrated Master in Informatics and Computing Engineering](https://sigarra.up.pt/feup/pt/cur_geral.cur_view?pv_curso_id=742) [MIEIC] at the [Faculty of Engineering of the University of Porto](https://sigarra.up.pt/feup/pt/web_page.Inicial) [FEUP].

4 | 5 |

Final Grade: 18/20

6 |

7 | FEUP Logo 12 |

13 | 14 | ## Here are several documents, namely: 15 | 16 | ### Notes 17 | Notes that I take during theoretical lectures in Markdown
18 | 19 | ### Project 1 (Grade: 18.6/20) 20 | 21 | File Transfer Protocol with Serial Port and Package Delection Error. 22 | 23 | ### Project 2 (Grade: 18.8/20) 24 | 25 | FTP Protocol implementation and Network structure. 26 | 27 | **@ Fábio Araújo de Sá**
28 | **2022/2023** 29 | -------------------------------------------------------------------------------- /Project1/main.c: -------------------------------------------------------------------------------- 1 | // Main file of the serial port project. 2 | // NOTE: This file must not be changed. 3 | 4 | #include 5 | #include 6 | #include 7 | 8 | #include "application_layer.h" 9 | 10 | #define BAUDRATE 9600 11 | #define N_TRIES 3 12 | #define TIMEOUT 4 13 | 14 | // Arguments: 15 | // $1: /dev/ttySxx 16 | // $2: tx | rx 17 | // $3: filename 18 | int main(int argc, char *argv[]) 19 | { 20 | if (argc < 4) 21 | { 22 | printf("Usage: %s /dev/ttySxx tx|rx filename\n", argv[0]); 23 | exit(1); 24 | } 25 | 26 | srand(time(NULL)); 27 | const char *serialPort = argv[1]; 28 | const char *role = argv[2]; 29 | const char *filename = argv[3]; 30 | 31 | printf("Starting link-layer protocol application\n" 32 | " - Serial port: %s\n" 33 | " - Role: %s\n" 34 | " - Baudrate: %d\n" 35 | " - Number of tries: %d\n" 36 | " - Timeout: %d\n" 37 | " - Filename: %s\n", 38 | serialPort, 39 | role, 40 | BAUDRATE, 41 | N_TRIES, 42 | TIMEOUT, 43 | filename); 44 | 45 | applicationLayer(serialPort, role, BAUDRATE, N_TRIES, TIMEOUT, filename); 46 | 47 | return 0; 48 | } 49 | -------------------------------------------------------------------------------- /Project1/include/application_layer.h: -------------------------------------------------------------------------------- 1 | // Application layer protocol header. 2 | // NOTE: This file must not be changed. 3 | 4 | #ifndef _APPLICATION_LAYER_H_ 5 | #define _APPLICATION_LAYER_H_ 6 | 7 | #include 8 | 9 | // Application layer main function. 10 | // Arguments: 11 | // serialPort: Serial port name (e.g., /dev/ttyS0). 12 | // role: Application role {"tx", "rx"}. 13 | // baudrate: Baudrate of the serial port. 14 | // nTries: Maximum number of frame retries. 15 | // timeout: Frame timeout. 16 | // filename: Name of the file to send / receive. 17 | void applicationLayer(const char *serialPort, const char *role, int baudRate, 18 | int nTries, int timeout, const char *filename); 19 | 20 | unsigned char* parseControlPacket(unsigned char* packet, int size, unsigned long int *fileSize); 21 | 22 | void parseDataPacket(const unsigned char* packet, const unsigned int packetSize, unsigned char* buffer); 23 | 24 | unsigned char * getControlPacket(const unsigned int c, const char* filename, long int length, unsigned int* size); 25 | 26 | unsigned char * getDataPacket(unsigned char sequence, unsigned char *data, int dataSize, int *packetSize); 27 | 28 | unsigned char * getData(FILE* fd, long int fileLength); 29 | 30 | #endif // _APPLICATION_LAYER_H_ 31 | -------------------------------------------------------------------------------- /Project2/pipe.txt: -------------------------------------------------------------------------------- 1 | ..... ... . . . . 2 | ........ . ..... . . ........ . . . 3 | ........ . ... . . ...... . ... . 4 | .... . . ..,*//////*.. .. . 5 | ... . %#/,*******,**#&&&% (&&&&&&%&%%%&%&&&%* 6 | ......,#(*,,((%%%%%&&&@@@& /&%(,,,/#&@@@@&@@(,..../(. 7 | .......%#(,,*(#%%%%%&&&@@@&* &%(,.,#&@@@@@#.. 8 | .. .%#(,,*(#%%%%%&&@@@@&(. (%/*../&@@@@@(. 9 | ....%#(,,*(#%%%&%&&@@@@@/ ##/***(#%#&@@& 10 | ... . #%(*,*(#%%%%%&@@@@@@* ,##//**(#%&&&&%. 11 | . . .%#/,*(#%%&%&&@@@@@@, *%#/**,*(#%&@@&&% 12 | %#(//(#%&%%&&@@@@@@&#((/**,*/(#%&@@@&&% 13 | .. . .%#(((#%%%&&@@@@@@@%#(((#%%%&@@@@@&% 14 | . . .%%%%%%%&@@@@@@@@@@@@@@@@@@@@@&&. 15 | .. .. /&&&&&@@@@@@@@@@@@@@@@@@&&% 16 | .. .&&&&@@@@@@@@@@@&&%. 17 | .. . . .. . 18 | .. .... 19 | ...... . . . 20 | ...... ..% .. .. .. . .. % . / . ,* * %# * %* ## 21 | .. . . ....#*..%.%.(... %/ ././#%%. ../(.#/,# %(,, /%.( *.(,.* %.%#./ 22 | .................... .. . . . . . .... . .. 23 | ...................... ... ... . . ...... 24 | -------------------------------------------------------------------------------- /Project1/README.md: -------------------------------------------------------------------------------- 1 | # RCOM Project 2 | 3 | ## Project Structure 4 | 5 | - bin/: Compiled binaries. 6 | - src/: Source code for the implementation of the link-layer and application layer protocols. Students should edit these files to implement the project. 7 | - include/: Header files of the link-layer and application layer protocols. These files must not be changed. 8 | - cable/: Virtual cable program to help test the serial port. This file must not be changed. 9 | - main.c: Main file. This file must not be changed. 10 | - Makefile: Makefile to build the project and run the application. 11 | - penguin.gif: Example file to be sent through the serial port. 12 | 13 | ## Instructions to Run the Project 14 | 15 | 1. Edit the source code in the src/ directory. 16 | 2. Compile the application and the virtual cable program using the provided Makefile. 17 | 3. Run the virtual cable program (either by running the executable manually or using the Makefile target): 18 | 19 | ```bash 20 | $ ./bin/cable_app 21 | $ make run_cable 22 | ``` 23 | 24 | 4. Test the protocol without cable disconnections and noise 25 | 26 | 4.1 Run the receiver (either by running the executable manually or using the Makefile target): 27 | 28 | ```bash 29 | $ ./bin/main /dev/ttyS11 rx penguin-received.gif 30 | $ make run_tx 31 | ``` 32 | 33 | 4.2 Run the transmitter (either by running the executable manually or using the Makefile target): 34 | 35 | ```bash 36 | $ ./bin/main /dev/ttyS10 tx penguin.gif 37 | $ make run_rx 38 | ``` 39 | 40 | 4.3 Check if the file received matches the file sent, using the diff Linux command or using the Makefile target: 41 | 42 | ```bash 43 | $ diff -s penguin.gif penguin-received.gif 44 | $ make check_files 45 | ``` 46 | 47 | 5. Test the protocol with cable disconnections and noise 48 | 5.1. Run receiver and transmitter again 49 | 5.2. Quickly move to the cable program console and press 0 for unplugging the cable, 2 to add noise, and 1 to normal 50 | 5.3. Check if the file received matches the file sent, even with cable disconnections or with noise 51 | 52 | ## Members 53 | 54 | ##### 3LEIC05 Group 05 55 | 56 | - Fábio Araújo de Sá (up202007658@fe.up.pt) 57 | - Lourenço Alexandre Correia Gonçalves (up202004816@fe.up.pt) -------------------------------------------------------------------------------- /Project1/include/link_layer.h: -------------------------------------------------------------------------------- 1 | // Link layer header. 2 | 3 | #ifndef _LINK_LAYER_H_ 4 | #define _LINK_LAYER_H_ 5 | 6 | #include 7 | #include 8 | #include 9 | #include 10 | #include 11 | #include 12 | #include 13 | #include 14 | #include 15 | #include 16 | 17 | #define _POSIX_SOURCE 1 18 | #define BAUDRATE 38400 19 | #define MAX_PAYLOAD_SIZE 1000 20 | 21 | #define BUF_SIZE 256 22 | #define FALSE 0 23 | #define TRUE 1 24 | 25 | #define FLAG 0x7E 26 | #define ESC 0x7D 27 | #define A_ER 0x03 28 | #define A_RE 0x01 29 | #define C_SET 0x03 30 | #define C_DISC 0x0B 31 | #define C_UA 0x07 32 | #define C_RR(Nr) ((Nr << 7) | 0x05) 33 | #define C_REJ(Nr) ((Nr << 7) | 0x01) 34 | #define C_N(Ns) (Ns << 6) 35 | 36 | typedef enum 37 | { 38 | LlTx, 39 | LlRx, 40 | } LinkLayerRole; 41 | 42 | typedef enum 43 | { 44 | START, 45 | FLAG_RCV, 46 | A_RCV, 47 | C_RCV, 48 | BCC1_OK, 49 | STOP_R, 50 | DATA_FOUND_ESC, 51 | READING_DATA, 52 | DISCONNECTED, 53 | BCC2_OK 54 | } LinkLayerState; 55 | 56 | typedef struct 57 | { 58 | char serialPort[50]; 59 | LinkLayerRole role; 60 | int baudRate; 61 | int nRetransmissions; 62 | int timeout; 63 | } LinkLayer; 64 | 65 | // Open a connection using the "port" parameters defined in struct linkLayer. 66 | // Return "1" on success or "-1" on error. 67 | int llopen(LinkLayer connectionParameters); 68 | 69 | // Send data in buf with size bufSize. 70 | // Return number of chars written, or "-1" on error. 71 | int llwrite(int fd, const unsigned char *buf, int bufSize); 72 | 73 | // Receive data in packet. 74 | // Return number of chars read, or "-1" on error. 75 | int llread(int fd, unsigned char *packet); 76 | 77 | // Close previously opened connection. 78 | // if showStatistics == TRUE, link layer should print statistics in the console on close. 79 | // Return "1" on success or "-1" on error. 80 | int llclose(int fd); 81 | 82 | // retorna fd ou -1 se der erro 83 | int connection(const char *serialPort); 84 | 85 | // timeout 86 | void alarmHandler(int signal); 87 | 88 | unsigned char readControlFrame (int fd); 89 | 90 | int sendSupervisionFrame(int fd, unsigned char A, unsigned char C); 91 | 92 | #endif // _LINK_LAYER_H_ 93 | -------------------------------------------------------------------------------- /Project2/network/6 - TCP connections.md: -------------------------------------------------------------------------------- 1 | # 2.6 - TCP connections 2 | 3 | >## Steps 4 | > 5 | >1. No Tux53, fazer o download de um ficheiro do servidor FTP. Guardar a captura obtida com o WireShark. 6 | >2. No Tux53 e no Tux52, fazer o download de um ficheiro do servidor FTP ao mesmo tempo. Guardar a captura obtida com o WireShark. 7 | 8 | ## Questions 9 | 10 | How many TCP connections are opened by your ftp application? 11 | 12 | ```note 13 | Duas: uma para enviar comandos e outra para receber o ficheiro. 14 | ``` 15 | 16 | In what connection is transported the FTP control information? 17 | 18 | ```note 19 | A primeira mencionada em cima, onde há transferência de comandos de controlo e recepção de mensagens do servidor. 20 | ``` 21 | 22 | ![Flow 1: Begin](../img/Exp6a.png) 23 | ![Flow 2: End](../img/Exp6b.png) 24 | 25 | What are the phases of a TCP connection? 26 | 27 | ```note 28 | DNS, conexão (SYN ACL), configuração, transferência do ficheiro, finalização (FIN ACK). 29 | ``` 30 | 31 | ![Graph 1: One TCP connection](../img/Exp6c.png) 32 | 33 | How does the ARQ TCP mechanism work? What are the relevant TCP fields? What relevant information can be observed in the logs? 34 | 35 | ```note 36 | Automatic Repeat Request serve para fazer retransmissão numa rede congestionada. Uma rede diz-se congestionada a partir do momento que se perdem pacotes. É necessário o envio de vários pacotes de uma vez (Additive Increase) até que tal aconteça. Usa-se slow start quando em vez de adicionar uma unidade à CongestionWindow em cada transmissão, usa-se o mesmo método mas em modo exponencial na base dois. A perda do pacote pode ser dada: 37 | - Por timeout. Ocorre um Multiplicative Decrease, passando a Congestion Window a 1 e aumentando novamente até metade do valor obtido por mecanismo de slow start. A partir de metade o Additive Increase passa a ser incremental de uma unidade; 38 | - Por 3 ACKs seguidos. Ocorre um Multiplicative Decrease, passando a Congestion Window a metade e Additive Increase passa a ser incremental de uma unidade; 39 | ``` 40 | 41 | How does the TCP congestion control mechanism work? What are the relevant fields. How did the through put of the data connection evolve along the time? Is it according the TCP congestion control mechanism? 42 | 43 | ```note 44 | Cada emissor determina a capacidade da comunicação para poder enviar mais ou menos pacotes. Para isso há mais um parâmetro na conexão (CongestionWindow). Se o nível de congestionamento da rede aumenta a CongestionWindow diminui e vice-versa. 45 | ``` 46 | 47 | Is the throughput of a TCP data connections disturbed by the appearance of a second TCP connection? How? 48 | 49 | ```note 50 | Sim, ao fazer mais de uma conexão TCP a largura de banda será dividida entre as multiplas ligações, reduzindo a velocidade de cada uma. 51 | ``` 52 | 53 | ![Graph 2: Two TCP connections](../img/Exp6d.png) 54 | -------------------------------------------------------------------------------- /Notes/8 - Routing.md: -------------------------------------------------------------------------------- 1 | # 8 - Routing 2 | 3 | As redes de computadores podem ser vistas como um grafo, onde se constroi uma árvore de caminhos mínimos (*ShortestPath Tree*) usando os algoritmos de Dijkstra ou Bellman-Ford. 4 | 5 | A escolha de um bom caminho (boa largura de banda, curta distância, baixa latência) é importante para garantir a eficiência da rede e limitar a quantidade de pacotes perdidos no processo. 6 | 7 | ## Routing in Layer 3 Networks 8 | 9 | Cada router conhece a rede e contém uma Fowarding Table, construída com base nos destinos dos pacotes a transferir e na sua própria Spanning Tree. Escolhe sempre o caminho mais curto, se o custo de cada ligação for o mesmo, ou o caminho com menos custo total. 10 | 11 | ### Link-State Routing 12 | 13 | #### Forma 1 - Dijkstra 14 | 15 | Cada um dos routers emite periodicamente (tipicamente de meia em meia hora) uma mensagem em **broadcast** contendo a sua identificação, a identificação dos routers diretamente ligados e os custos associados. Assim conseguem manter o grafo da rede e a própria Fowarding Table atualizados. A mensagem pode ser imediatamente lançada quando algum router detecta uma nova ligação ou perda (através de mensagens *"hello"*). Por um lado as informações trocadas são mais localizadas e menores, mas por outro qualquer modificação na rede distante acaba por demorar muito tempo a chegar a todos os routers. 16 | 17 | #### Forma 2 - Bellman 18 | 19 | Através do Algoritmo de `Bellman-Ford` as mensagens são enriquecidas com o conhecimento cada vez mais vasto da rede: dos vizinhos, dos vizinhos dos vizinhos... através da troca das Fowarding Tables correspondentes. Aqui as mensagens são mais longas, pois acabam por conter a informação das tabelas todas, mas por outro lado as modificações são rapidamente transportadas para todos os routers. 20 | 21 | ### Routing Information Protocol (RIP) 22 | 23 | É o protocolo que gere a distância entre routers. Os routers enviam a sua distância aos outros de 30 em 30 segundos ou quando um update causa uma modificação na rede em si. 24 | 25 | ## Routing in Layer 2 Networks 26 | 27 | ### Spanning Tree Protocol (STP) 28 | 29 | Protocolo existente nas bridges presentes nos switches da rede. Aqui os routers não constroem as suas próprias Spanning Tree, existindo apenas uma árvore no sistema que é construída por mensagens trocadas entre switches. As mensagens são do tipo (Y, d, X): 30 | 31 | > M (Y, d, X)
32 | > Y <- Root da árvore atual
33 | > d <- Distância de ligação
34 | > X <- Origem
35 | 36 | Inicialmente todos os switches assumem que eles próprios são a raiz da árvore. À medida que as mensagens são trocadas, os switches admitem sempre que a raiz da árvore é agora o switch que contém o menor número identificador. Os switches bloqueiam algumas portas para que não existam ciclos. 37 | 38 | ### Fluxo Máximo 39 | 40 | Cada ligação do grafo da rede representa agora a capacidade em bits/segundo. O fluxo máximo é igual ao corte de capacidade mínima. 41 | 42 | > Número máximo de cortes possíveis num grafo de V vértices:
43 | > 2^(V - 1)
-------------------------------------------------------------------------------- /Notes/1 - Introduction.md: -------------------------------------------------------------------------------- 1 | # 1 - Introduction of Computer Networks 2 | 3 | As redes de computadores são utilizadas por diversos fins no nosso quotidiano (email, web, remote login, games, vídeos, streaming).
4 | Há, para isso, duas arquiteturas de aplicações principais: 5 | 6 | ## Application Architectures 7 | 8 | ### 1 - Client-server 9 | 10 | O cliente comunica diretamente com o servidor (um always-on computer) mas não com outros clientes. O servidor têm um IP permanente e um nome conhecido. Um exemplo é a comunicação entre browsers e servidores, através de HTTP requests. 11 | 12 | ### 2 - Peer-to-peer (P2P) 13 | 14 | Não há um servidor always-on mas sim sistemas arbitrários para comunicar diretamente (tal como outros clientes). Um exemplo é a distribuição de ficheiros: há torrent, que é um grupo de pessoas que partilham partes de um ficheiro, e o servidor, que é um tracker que controla quem faz parte do torrent. 15 | 16 | ## Tipos de Redes 17 | 18 | As redes podem ser classificadas de acordo com a área/extensão de atuação: 19 | 20 | 1. **PAN - Personal Area Network**, 1 metro, bluetooth entre dispositivos de uma secretária; 21 | 2. **LAN - Local Area Network**, 10 metros a 1 quilómetro, no quarto, construção ou campus. É exemplo a rede da FEUP, que tem switches, routers e access points; 22 | 3. **MAN - Metropolitan Area Network**, 10 quilómetros, onde pode conter uma antena e servidores;s, protocols, an 23 | 4. **WAN - Wide Area Network**, engloba um continente; 24 | 5. **Internet - no Planeta**, é um conjunto de redes conectadas; 25 | 26 | ## Protocol Stacks 27 | 28 | A comunicação entre dois ou mais Hosts é feita segundo um modelo de black box. As camadas superiores usam as APIs dadas pelas camadas inferiores para criar o seu protocolo. 29 | 30 |

31 | 32 |

Figura 1: Layers

33 |

34 | 35 | Cada camada trata de criar headers próprios para que a informação contida em cada pacote seja correctamente identificada e transportada. É comum nos serviços existirem 5 camadas principais para transferência da informação: 36 | 37 | 1. **Application layer**: suporta a aplicação propriamente dita. É a camada mais externa da transferência. São exemplos o FTP, SMTP, HTTP. 38 | 2. **Transport layer**: Process-process / end-to-end. Como os protocolos TCP, UDP. 39 | 3. **Network layer**: roteamento dos pacotes desde a fonte para o destino. Por exemplo os IP. 40 | 4. **Data Link layer**: informação transferida entre os elementos das redes vizinhas. São exemplos PPP, Ethernet e WLAN. 41 | 5. **Physical layer**: os bits que são transferidos. 42 | 43 | ## Transferência da informação: 44 | 45 | ### Circuit Switching 46 | 47 | A comunicação é só feita após uma ligação bem estabelecida entre a fonte e o receptor (e entre os intermediários). Após isso os dados são enviados de uma vez. Há um delay no início para estabelecimento da ligação. 48 | 49 | ### Packet Switching 50 | 51 | A informação está concebida em pacotes que são enviados sequencialmente entre todos os intermediários e segundo a ordem da fila. -------------------------------------------------------------------------------- /Notes/9 - Application Layer.md: -------------------------------------------------------------------------------- 1 | # 9 - Application Layer 2 | 3 | Esta camada define os tipos de mensagens trocadas, a sintaxe e semântica delas e as regras de envio e resposta por parte dos processos. Enquanto que os protocolos TCP e UDP não oferecem segurança, o TLS (*Transport Layer Security*) encripta todas as mensagens enviadas e torna a ligação ponta-a-ponta usando certificados como autenticadores. 4 | 5 | ## HTTP - Hypertext Transfer Protocol 6 | 7 | É um protocolo que não tem estado, na medida em que o servidor não armazena informação de sessões ou pedidos anteriores. Os pedidos têm um cabeçalho, que evidencia o tipo de pedido (GET, POST, PUT, DELETE), e as respostas também podem conter corpo com o payload solicitado.
8 | 9 | O estado pode ser conhecido através de *cookies* e o sistema pode ser mais rápido com *proxy servers* que guardam as respostas HTTP anteriores em cache. 10 | 11 | ### HTTP Não persistente 12 | 13 | Permite o envio e recepção de no máximo um objecto por conexão TCP. Sendo RTT o tempo para um pacote viajar do cliente para o servidor e voltar, então o tempo total para uma resposta é dado por: 14 | 15 | > response_time = 2 * RTT + transfer_time
16 | > inicialização de uma conexão TCP (RTT)
17 | > pedido do ficheiro (RTT)
18 | > trasferência do ficheiro (transfer_time)
19 | 20 | ### HTTP Persistente 21 | 22 | Permite troca de vários objectos numa única conexão TCP, ou seja, o servidor deixa a conexão aberta após mandar a resposta. Assim as mensagens seguintes entre o mesmo par cliente-servidor deixam de iniciar uma nova ligação TCP, poupando tempo. A persistência pode ser: 23 | - `sem pipelining`, quando o cliente manda um request apenas quando recebe a resposta anterior, utilizando um RTT para cada novo pedido; 24 | - `com pipelining`, quando o cliente manda vários requests sem esperar pela resposta, utilizando um RTT para todas as requests que enviar; 25 | 26 | ## Eletronic Mail 27 | 28 | O serviço de email é constituido por três grandes pilares: os utilizadores, os servidores de email e o protocolo de transporte SMTP (*Simple Mail Transfer Protocol*). As mensagens enviadas ficam numa fila de espera para serem enviadas entre servidores antes de seguirem para o destino final. Usam conexões persistentes e as mensagens trocadas (cabeça e corpo) têm de ser codificadas em ASCII de 7 bits. 29 | 30 | Usam-se ainda os protocolos: 31 | - IMAP (*Internet Mail Access Protocol*), para manipulação das mensagens existentes no servidor. Guarda o estado entre sessões; 32 | - POP3 (*Post Office Protocol*), para autorização de conexão entre o cliente e o servidor e para downloads de mensagens entre serviços. Não guarda o estado entre sessões; 33 | 34 | ## DNS - Domain Name System 35 | 36 | É uma base de dados distribuída implementada com hierarquia que é capaz de traduzir os nomes dos servidores nos respectivos endereços IP. É descentralizada para não haver o ponto único de falha, por distribuição de tráfego e manutenção. Os servidores TLD (*Top Level Domain*) são responsáveis pelas terminações mais comuns de sites, enquanto os *Authoritative* são responsáveis por tradução de IPs de organizações de Web e Mail. Cada ISP contém um `Local Name Server`, que é o default. -------------------------------------------------------------------------------- /Project2/network/2 - Implement two bridges in a switch.md: -------------------------------------------------------------------------------- 1 | # 2.2 Implement two bridges in a switch 2 | 3 | ## Steps 4 | 5 | > 1. Conectar Tux52_S0 em T3; 6 | > 2. Conectar o T4 no CONSOLE do switch; 7 | > 3. Abrir o GKTerm no Tux52 e configurar a baudrate para 115200; 8 | > 4. Resetar as configurações do switch com o seguinte comando: 9 | > 10 | > ```bash 11 | > > admin 12 | > > /system reset-configuration 13 | > > y 14 | > ``` 15 | > 16 | > 5. Conectar o Tux52_E0 ao switch (porta 3) e configurar a ligaçao com os seguintes comandos: 17 | > 18 | > ```bash 19 | > $ ifconfig eth0 up 20 | > $ ifconfig eth0 172.16.51.1/24 21 | > ``` 22 | > 23 | > 6. Criar 2 bridges no switch 24 | > 25 | > ```bash 26 | > > /interface bridge add name=bridge50 27 | > > /interface bridge add name=bridge51 28 | > ``` 29 | > 30 | > 7. Eliminar as portas as quais o Tux52, 53 e 54 estao ligados por defeito 31 | > 32 | > ```bash 33 | > > /interface bridge port remove [find interface=ether1] 34 | > > /interface bridge port remove [find interface=ether2] 35 | > > /interface bridge port remove [find interface=ether3] 36 | > ``` 37 | > 38 | > 8. Adicionar as novas portas 39 | > 40 | > ```bash 41 | > > /interface bridge port add bridge=bridge50 interface=ether1 42 | > > /interface bridge port add bridge=bridge50 interface=ether2 43 | > > /interface bridge port add bridge=bridge51 interface=ether3 44 | > ``` 45 | > 46 | > 9. Verificar que as portas foram adicionadas corretamente com o commando : 47 | > 48 | > ```bash 49 | > > /interface bridge port print 50 | > ``` 51 | > 52 | > 10. Começar a captura do eth0 do Tux53 53 | > 54 | > 11. Desde o Tux53, começar a captura do eth0 e fazer ping do Tux54 e Tux52 55 | > ```bash 56 | > $ ping 172.16.50.254 57 | > #Tux55 -> Tudo ok 58 | > $ ping 172.16.51.1 59 | > #Tux52 -> connect: Network is unreachable 60 | > ``` 61 | > 62 | > 12. Começar capturas do eth0 no Tux52, Tux53 e Tux54. No Tux53, executar o seguinte comando e observar e guardar os resultados: 63 | > ```bash 64 | > $ ping -b 172.16.50.255 65 | > ``` 66 | > 67 | > 13. Começar capturas do eth0 no Tux52, Tux53 e Tux54. No Tux52, executar o seguinte comando e observar e guardar os resultados: 68 | > ```bash 69 | > $ ping -b 172.16.51.255 70 | > ``` 71 | 72 | ## Questions 73 | 74 | How to configure bridgeY0? 75 | 76 | ```note 77 | A bridge50 foi configurada para servir de meio de ligação entre os computadores Tux53 e Tux54, formando uma subrede. Eliminamos as configurações e ligações por omissão que o switch implementou aquando da ligação entre os computadores e configuramos novas portas/ligações a cada um dos computadores. Os comandos utilizados no processo estão disponíveis acima. 78 | ``` 79 | 80 | How many broadcast domains are there? How can you conclude it from the logs? 81 | 82 | ```note 83 | Existem dois domínios de broadcast pois existem duas bridges implementadas. Analisando os logs, reparamos que o ping do Tux53 conseguiu resposta do Tux54 mas não do Tux52, pois estão inseridos em duas bridges diferentes. 84 | ``` 85 | 86 | Ping do Tux53 87 | 88 | ![Resultados do WireShark](../img/Exp2a.png) 89 | 90 | Ping do Tux52 91 | 92 | ![Resultados do WireShark](../img/Exp2b.png) -------------------------------------------------------------------------------- /Project2/network/1 - Configure an IP Network.md: -------------------------------------------------------------------------------- 1 | # 2.1 Configurate an IP Network 2 | 3 | > ## Steps 4 | > 5 | > 1. Conectar E0 do Tux53 e do Tux54 numa das entradas do switch; 6 | > 2. Aceder a cada um dos computadores e configurar os seus IPs: 7 | > 8 | > ```bash 9 | > $ ifconfig eth0 up 10 | > $ ifconfig eth0 11 | > - 172.16.50.1/24 para o Tux53 12 | > - 172.16.50.254/24 para o Tux54 13 | > ``` 14 | > 15 | > 3. Para ver o MAC address de cada computador, consultar o campo `ether` no comando `ipconfig`; 16 | > 4. Verificar a conexão dos dois computadores na mesma rede. Em cada um tenta enviar pacotes de dados para outro. A conexão está correcta quando todos os pacotes são recebidos: 17 | > 18 | > ```bash 19 | > $ ping -c 20 20 | > - 172.16.50.254 para o Tux53 21 | > - 172.16.50.1 para o Tux54 22 | > ``` 23 | > 24 | > 5. Avaliar a tabela *Address Resolution Protocol* (ARP) do Tux53. Deverá ter uma única entrada com o IP e o MAC do Tux54. Para visualizar a tabela: 25 | > 26 | > ```bash 27 | > $ arp -a # ?(172.16.50.254) at 00:21:5a:c3:78:70 [ether] on eth0 28 | > ``` 29 | > 30 | > 6. Apagar a entrada da tabela ARP do Tux53: 31 | > 32 | > ```bash 33 | > $ arp -d 172.16.50.254/24 34 | > $ arp -a # empty 35 | > ``` 36 | > 37 | > 7. Abrir o WireShark no Tux53 e começar a capturar pacotes de rede; 38 | > 8. Executar o seguinte comando no Tux53: 39 | > 40 | > ```bash 41 | > $ ping 172.16.50.254/24 -c 10 42 | > ``` 43 | > 44 | > 9. Parar a captura dos resultados e avaliar os logs obtidos com o WireShark. 45 | > 46 | > ![Resultados do WireShark](../img/Exp1.png) 47 | 48 | ## Questions 49 | 50 | What are the ARP packets and what are they used for? 51 | 52 | ```note 53 | Os pacotes ARP (*Address Resolution Protocol*) são pacotes que servem para estabelecer a ligação entre um IP e um endereço MAC. 54 | ``` 55 | 56 | What are the MAC and IP addresses of ARP packets and why? 57 | 58 | ```note 59 | São enviados em broadcast 2 endereços IP: o da máquina de destino (172.16.50.254, Tux54) e o da máquina de origem (172.16.50.01, Tux 53) no mesmo pacote ARP. Como resposta o Tux54 envia um pacote ARP para o Tux53 que contém o seu endereço MAC, 00:21:5a:c3:78:70. 60 | ``` 61 | 62 | What packets does the ping command generate? 63 | 64 | ```note 65 | Enquanto não obtém o endereço MAC da máquina de destino, o *ping* gera pacotes ARP. Após fazer a ligação do endereço IP ao respetivo MAC, gera pacotes do tipo ICMP (*Internet Control Message Protocol*), para transferência de informação. 66 | ``` 67 | 68 | What are the MAC and IP addresses of the ping packets? 69 | 70 | ```note 71 | Os endereços IP e MAC usados em pacotes ICMP são os das máquinas em comunicação: Tux53 e Tux54. 72 | ``` 73 | 74 | How to determine if a receiving Ethernet frame is ARP, IP, ICMP? 75 | 76 | ```note 77 | A designação do protocolo de cada frame está presente na coluna "Protocol" da captura no Wireshark. Por norma o protocolo é indicado nos primeiros 2 bytes da frame, no cabeçalho. 78 | ``` 79 | 80 | How to determine the length of a receiving frame? 81 | 82 | ```note 83 | Existe uma coluna no Wireshark que mostra o tamanho, em bytes, das frames. Por norma o cabeçalho de cada frame contém essa informação. 84 | ``` 85 | 86 | What is the loopback interface and why is it important? 87 | 88 | ```note 89 | É uma interface virtual que é sempre alcançável desde que pelo menos uma das interfaces IP do *switch* esteja operacional. Com isto, é possível verificar periodicamente se as ligações da rede estão configuradas corretamente. 90 | ``` -------------------------------------------------------------------------------- /Project2/network/3 - Configure a Router in Linux.md: -------------------------------------------------------------------------------- 1 | # 2.3 Configure a Router in Linux 2 | 3 | >## Steps 4 | > 5 | > 1. Ligar eth1 do Tux54 à porta 4 do switch. Configurar eth1 do Tux54 6 | > ```bash 7 | > ifconfig eth1 up 8 | > ifconfig eth1 172.16.51.253/24 9 | > ``` 10 | > 11 | > 2. Eliminar as portas as quais o Tux52 esta ligado por defeito e adicionar a nova porta 12 | > ```bash 13 | > /interface bridge port remove [find interface=ether4] 14 | > /interface bridge port add bridge=bridge51 interface=ether4 15 | > ``` 16 | > 17 | > 3. Ativar *ip forwarding* e desativar ICMP no Tux54 18 | > ```bash 19 | > #3 Ip forwarding t4 20 | > echo 1 > /proc/sys/net/ipv4/ip_forward 21 | > 22 | > #4 Disable ICMP echo ignore broadcast T4 23 | > echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 24 | > ``` 25 | > 26 | > 4. Observar MAC e Ip no Tux54eth0 e Tux54eth1 27 | > ```bash 28 | > ifconfig 29 | > ##Mac eth0 -> 00:21:5a:c3:78:70 30 | > ##ip eth0-> 172.16.50.254 31 | > ##Mac eth1 -> 00:c0:df:08:d5:b0 32 | > ##ip eth1-> 172.16.51.253 33 | > ``` 34 | > 35 | > 5. Adicionar as seguintes rotas no Tux52 e Tux53 para que estes se consigam altançar um ou outro através do Tux54 36 | > ```bash 37 | > route add -net 172.16.50.0/24 gw 172.16.51.253 # no Tux52 38 | > route add -net 172.16.51.0/24 gw 172.16.50.254 # no Tux53 39 | > ``` 40 | > 41 | > 6. Verificar as rotas em todos os Tux com o seguinte comando: 42 | > ```bash 43 | > route -n 44 | > ``` 45 | > 46 | > 7. Começar captura do Tux53 no Wireshark 47 | > 48 | > 8. Fazer ping aos seguintes endereços desde o Tux53 49 | > ```bash 50 | > ping 172.16.50.254 51 | > ping 172.16.51.253 52 | > ping 172.16.51.1 53 | > ##All good, network is correct 54 | > ``` 55 | > 56 | > 9. Parar a captura e guardar os resultados 57 | > 58 | > 10. Começar captura do eth0 e eth1 do Tux54 no Wireshark 59 | > 60 | > 11. Limpar as tabelas ARP em todos os Tux 61 | > ```bash 62 | > arp -d 172.16.51.253 #Tux52 63 | > arp -d 172.16.50.254 #Tux53 64 | > arp -d 172.16.50.1 #Tux54 65 | > arp -d 172.16.51.1 #Tux54 66 | > ``` 67 | > 68 | > 12. Fazer ping do Tux52 desde o Tux53 69 | > 70 | > 13. Parar a captura e guardar os resultados 71 | 72 | ## Questions 73 | 74 | What routes are there in the tuxes? What are their meaning? 75 | 76 | ```note 77 | Existe uma rota no Tux52 e outra no Tux53. Ambas têm como *gateway* o Tux54 pois é o único que é comum às duas bridges criadas (router). 78 | ``` 79 | 80 | What information does an entry of the forwarding table contain? 81 | 82 | ```note 83 | Cada entrada contém o endereço de destino e respetivo gateway. 84 | ``` 85 | 86 | What ARP messages, and associated MAC addresses, are observed and why? 87 | 88 | ```note 89 | Embora o ping seja do Tux53 para o Tux52, os pacotes ARP trocados contém apenas os MAC addresses do Tux53 e do Tux54 e não do destino final. Isto deve-se à implementação da rota. O endereço de Tux52 não é conhecido pelo Tux53, este apenas conhece o endereço da gateway (Tux54) que leva ao Tux52. 90 | ``` 91 | 92 | ![Resultados do WireShark](../img/Exp3a.png) 93 | 94 | What ICMP packets are observed and why? 95 | 96 | ```note 97 | Os pacotes ICMP contém sempre o endereço de origem (IP do Tux53) e o endereço de destino (IP do Tux52). O facto de serem observados significa que a rede esta configurada corretamente. 98 | ``` 99 | 100 | ![Resultados do WireShark](../img/Exp3b.png) 101 | 102 | What are the IP and MAC addresses associated to ICMP packets and why? 103 | 104 | ```note 105 | Cada pacote ICMP observado através do ping no Tux53 contém como endereço de origem o IP do Tux53 e o endereço de destino o IP do Tux52. No entanto, esses pacotes contém o endereço MAC do Tux54, pois é o computador que faz a ligação entre as duas bridges. 106 | ``` -------------------------------------------------------------------------------- /Notes/2 - Physical Layer.md: -------------------------------------------------------------------------------- 1 | # Physical Layer 2 | 3 | São os canais reais usados na rede para transmitir e receber dados digitais. O sinal de transmissão de input pode ser modificado até ao receptor, com uma frequência que varia entre zero e o valor máximo BH. Um sinal também é composto por um número variado de ondas harmónicas. 4 | 5 | ## Reconstrução do sinal no receptor 6 | 7 | Nyquist provou que é possível reconstruir totalmente um sinal no receptor desde que exista uma banda BH e amostrado na taxa de 2B por segundo. Amostragem em taxa mais alta não fornece informações adicionais. A fórmula a reter é bitrate C = 2BH * log (M) 8 | 9 | ### Exemplo: 10 | 11 | Uma onda quadrada tem diferença de potencial que varia entre 5v e -5v (M = 2). A frequência do canal é de BH = 3kHz. Então deverá receber 2BH símbolos por segundo, ou seja, 6k, com cada símbolo a ser um bit de informação. 12 | 13 | Se M = 4, ou seja, há 4 níveis de diferença de potencial para enviar a informação, então o bitrate é 6k * log (4) = 12 kbits/s. 14 | 15 | ### Bandas 16 | 17 | 1. **Baseband**: O sinal tem uma frequência de zero até a um limite BH. É comum para fios; 18 | 2. **Passband**: O sinal usa uma banda de frequências em torno de uma frequência fixa FC. Comum para canais sem fio e óticos. 19 | 20 | ## Transmissão em BaseBand 21 | 22 | 1. **NRZ-L, Non Return to Zero Level**, há dois níveis, o mais baixo representa o 1; 23 | 2. **NRZ-I, Non Return to Zero Inverted**, há também dois níveis, mas a mudança de nível representa um 1; 24 | 3. **Manchester**, a transmissão é no meio do bit. Se descer é um 1, se subir é um 0. É muito usada na Ethernet. 25 | 26 | ### Clock Recovery 27 | 28 | Para descodificar os símbolos, o sinal precisa ter transições suficientes. Então é usada uma codificação Manchester que, por cada 4 bits de dados, manda também uma codificação de 5 bits respectivamente. 29 | 30 | ## Modulação 31 | 32 | Há 4 formas de transmitir os bits através da mudanças na fonte: 33 | 34 |

35 | 36 |

Figura 1: Modulation

37 |

38 | 39 | 1. **Sinal binário** - transição entre diferenças de potencial; 40 | 2. **Amplitude** - mudanças da amplitude no sinal quando há transmissão de 1; 41 | 3. **Frequência** - mudanças na frequência do sinal quando há transmissão de 1; 42 | 4. **Fase** - mudanças de fase / do formato da onde quando há transmissão de 1; 43 | 44 | ## Shannon's Law 45 | 46 | A máxima capacidade teórica de um canal é definida por: 47 | 48 | C = Bc * log (1 + Pr/(NOBC)) 49 | 50 | Com Bc a ser a taxa de amostragem, em símbolos/s, Pr a potência prevista pelo receptor, N0 a potência de ruído por unidade de largura de banda, NOBc potência de ruído dentro da largura de banda estipulada. Assim o termo do logarítimo representa Signal to Noise ratio (SNR). 51 | 52 | ### Notas importantes sobre a Shannon's Law 53 | 54 | - A capacidade do canal é proporcional à largura de banda; 55 | - Com um sinal significativamente superior ao nível de ruído, a capacidade é proporcional ao logaritmo de SNR. 56 | 57 | ### Conversão de unidades: 58 | 59 | Ambas com Potência P em W, temos que: 60 | - PdBW = 10*log10P 61 | - PdBm = 10*log10(P/1mW) 62 | 63 | ## Transmissões por cabos 64 | 65 | ### 1 - **Coaxiable** 66 | 67 | Como cabos das televisões. Têm uma alta largura de banda, boa imunidade a ruídos e baixas atenuações. 68 | 69 | ### 2 - **UTP - Twisted pair** 70 | 71 | Os fios são trançados e não protegidos dentro de um fio maior. Aqui o ganho/atenuação em frequência é proporcional à distância percorrida. São exemplos os cabos de rede, como nos routers de casa. 72 | 73 | ### 3 - **Fiber optic** 74 | 75 | A transmissão é feita com base na reflexão total da luz, em altas larguras de banda, baixas atenuações (delays) e segundo o NRZ (luz 1, não luz 0). O comprimento de onda, C, é igual à velocidade da luz * período, e assim a velocidade de propagação é igual ao comprimento da onda * frequência. 76 | 77 | ## Free Space Loss 78 | 79 | Numa transmissão entre antenas, em espaço livre de outros obstáculos, a perda de potência entre antenas é definida como: 80 | 81 |

82 | 83 |

Figura 2: Free Space Loss

84 |

-------------------------------------------------------------------------------- /Project2/include/download.h: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | #include 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | #include 10 | #include 11 | 12 | #define MAX_LENGTH 500 13 | #define FTP_PORT 21 14 | 15 | /* Server responses */ 16 | #define SV_READY4AUTH 220 17 | #define SV_READY4PASS 331 18 | #define SV_LOGINSUCCESS 230 19 | #define SV_PASSIVE 227 20 | #define SV_READY4TRANSFER 150 21 | #define SV_TRANSFER_COMPLETE 226 22 | #define SV_GOODBYE 221 23 | 24 | /* Parser regular expressions */ 25 | #define AT "@" 26 | #define BAR "/" 27 | #define HOST_REGEX "%*[^/]//%[^/]" 28 | #define HOST_AT_REGEX "%*[^/]//%*[^@]@%[^/]" 29 | #define RESOURCE_REGEX "%*[^/]//%*[^/]/%s" 30 | #define USER_REGEX "%*[^/]//%[^:/]" 31 | #define PASS_REGEX "%*[^/]//%*[^:]:%[^@\n$]" 32 | #define RESPCODE_REGEX "%d" 33 | #define PASSIVE_REGEX "%*[^(](%d,%d,%d,%d,%d,%d)%*[^\n$)]" 34 | 35 | /* Default login for case 'ftp:///' */ 36 | #define DEFAULT_USER "anonymous" 37 | #define DEFAULT_PASSWORD "password" 38 | 39 | /* Parser output */ 40 | struct URL { 41 | char host[MAX_LENGTH]; // 'ftp.up.pt' 42 | char resource[MAX_LENGTH]; // 'parrot/misc/canary/warrant-canary-0.txt' 43 | char file[MAX_LENGTH]; // 'warrant-canary-0.txt' 44 | char user[MAX_LENGTH]; // 'username' 45 | char password[MAX_LENGTH]; // 'password' 46 | char ip[MAX_LENGTH]; // 193.137.29.15 47 | }; 48 | 49 | /* Machine states that receives the response from the server */ 50 | typedef enum { 51 | START, 52 | SINGLE, 53 | MULTIPLE, 54 | END 55 | } ResponseState; 56 | 57 | /* 58 | * Parser that transforms user input in url parameters 59 | * @param input, a string containing the user input 60 | * @param url, a struct that will be filled with the url parameters 61 | * @return 0 if there is no parse error or -1 otherwise 62 | */ 63 | int parse(char *input, struct URL *url); 64 | 65 | /* 66 | * Create socket file descriptor based on given server ip and port 67 | * @param ip, a string containing the server ip 68 | * @param port, an integer value containing the server port 69 | * @return socket file descriptor if there is no error or -1 otherwise 70 | */ 71 | int createSocket(char *ip, int port); 72 | 73 | /* 74 | * Authenticate connection 75 | * @param socket, server connection file descriptor 76 | * @param user, a string containing the username 77 | * @param pass, a string containing the password 78 | * @return server response code obtained by the operation 79 | */ 80 | int authConn(const int socket, const char *user, const char *pass); 81 | 82 | /* 83 | * Read server response 84 | * @param socket, server connection file descriptor 85 | * @param buffer, string that will be filled with server response 86 | * @return server response code obtained by the operation 87 | */ 88 | int readResponse(const int socket, char *buffer); 89 | 90 | /* 91 | * Enter in passive mode 92 | * @param socket, server connection file descriptor 93 | * @param ip, string that will be filled with data connection ip 94 | * @param port, string that will be filled with data connection port 95 | * @return server response code obtained by the operation 96 | */ 97 | int passiveMode(const int socket, char* ip, int *port); 98 | 99 | /* 100 | * Request resource 101 | * @param socket, server connection file descriptor 102 | * @param resource, string that contains the desired resource 103 | * @return server response code obtained by the operation 104 | */ 105 | int requestResource(const int socket, char *resource); 106 | 107 | /* 108 | * Get resource from server and download it in current directory 109 | * @param socketA, server connection file descriptor 110 | * @param socketB, server connection file descriptor 111 | * @param filename, string that contains the desired file name 112 | * @return server response code obtained by the operation 113 | */ 114 | int getResource(const int socketA, const int socketB, char *filename); 115 | 116 | /* 117 | * Closes the server connection and the socket itself 118 | * @param socketA, server connection file descriptor 119 | * @param socketB, server connection file descriptor 120 | * @return 0 if there is no close error or -1 otherwise 121 | */ 122 | int closeConnection(const int socketA, const int socketB); 123 | -------------------------------------------------------------------------------- /Notes/7 - Transport Layer.md: -------------------------------------------------------------------------------- 1 | # 7 - Transport Layer 2 | 3 | Nesta camada existem dois tipos de protocolos principais: 4 | 5 | ## User Datagram Protocol (UDP) 6 | 7 | Permite que uma aplicação envie diretamente dados, que serão colocados dentro de pacotes na rede com o mínimo overhead possível. Não é aconselhado pois apesar de conseguir detectar erros, não consegue revertê-los (por exemplo em falhas no payload, erros de envio/recepção). O Header do protocolo contém o número a porta que identifica os processos de origem e destino, o tamanho da trama e um checksum. 8 | 9 | ## Transmission Control Protocol (TCP) 10 | 11 | É orientado às comunicações, full-duplex (permite transferência nos dois sentidos) e incorpora dois mecanismos de controlo: o Controlo de Fluxo, que permite ao receptor controlar o fluxo de emissão de pacotes, e o Controlo de congestionamento, onde os emissores de dados não geram mais tráfego do que é possível transportar na rede.
12 | 13 | Do lado do **emissor**, a informação será partida em fragmentos, e a cada segmento enviado espera por ACK. Sempre que atinge o timeout ou a resposta for NACK, reenvia o mesmo fragmento. Do lado do **receptor**, os erros serão detectados através do checksum, os segmentos serão ordenados e os duplicados descartados. 14 | 15 | ### Cabeçalho do TCP 16 | 17 | - Número de portas, que são semelhantes ao UDP mas a transferência só começa a acontecer quando há comunicação estável estabelecida; 18 | - Os números de sequência (*SeqNumber*) são números de 32 bits que identificam a ordem do primeiro byte a ser enviado na zona de tramas de informação. É no *handshake* que os números iniciais das sequence numbers são trocados; 19 | - O *AckNumber* serve para indicar ao receptor qual é o próximo byte de resposta que está à espera (normalmente um byte a indicar um ACK) e garante a recepção correcta de todos os bytes de ordem inferior; 20 | - Window size; 21 | - Checksum, que cobre toda a trama (header e dados); 22 | 23 | ### Controlo de Fluxo 24 | 25 | Os buffers do lado do receptor e do transmissor são finitos, pelo que não podem receber mais do que a sua capacidade porque senão há perda de pacotes. Sempre que o receptor recebe um pacote, verifica se tem espaço e lança na resposta um parâmetro, `Advertise Window`, indicando a quantidade de espaço em bytes que ainda tem disponível. O transmissor faz então resize da próxima payload enviada, considerando o valor dado pela resposta e os bytes já enviados e cuja resposta ainda não foi recebida. 26 | 27 | ### Timeout 28 | 29 | Quando as redes são extensas e desconhecidas, é difícil prever o timeout adequado de espera por uma resposta. Usa-se o mecanismo **Addaptative Retransmission**, que é um algoritmo iterativo: 30 | 31 | > Com alpha = 0.125
32 | > Tempo de espera i = (1-alpha) * (tempo de espera i - 1) + alpha * (tempo de espera da resposta recebida em i)
33 | > Timeout i = Tempo de espera i
34 | 35 | No entanto este mecanismo ainda não é suficiente, pois a variância pode fazer esperar mais do que necessário. Assim é também necessário calculá-la e ajustar o tempo de timeout: 36 | 37 | > Com beta = 0.25
38 | > Variância em i = (1-beta) * (variância em i - 1) + beta * (variância calculada em i - tempo de espera da resposta recebida em i)
39 | > Timeout i = Tempo de espera i + 4 * Variância em i
40 | 41 | Estes cálculos não são efetuados quando há retransmissão de segmentos para evitar ambiguidade (há casos onde não dá para saber qual é a trama a que se refere a resposta). 42 | 43 | ### Selective ACK 44 | 45 | Há adição de uma bit mask dos pacotes recebidos, de forma a que a resposta contenha um identificador de qual trama se refere. Assim há retransmissão apenas dos pacotes selecionados e não todos. 46 | 47 | ### Controlo de Congestionamento 48 | 49 | Cada emissor determina a capacidade da comunicação para poder enviar mais ou menos pacotes. Para isso há mais um parâmetro na conexão (*CongestionWindow*): 50 | 51 | > MaxWin = MIN(CongestionWindow, AdvertisedWindow)
52 | > EffWin = MaxWin - (LastByteSent - LastByteAcked)
53 | > Bitrate = CongestionWindow / Round Trip Time
54 | 55 | Assim, se o nível de congestionamento da rede aumenta a CongestionWindow diminui e vice-versa. 56 | 57 | #### Como verificar a existência de congestionamento ? 58 | 59 | Uma rede diz-se congestionada a partir do momento que se perdem pacotes. É necessário o envio de vários pacotes de uma vez (*Additive Increase*) até que tal aconteça. Usa-se `slow start` quando em vez de adicionar uma unidade à CongestionWindow em cada transmissão, usa-se o mesmo método mas em modo exponencial na base dois. A perda do pacote pode ser dada: 60 | 61 | - Por `timeout`. Ocorre um *Multiplicative Decrease*, passando a Congestion Window a 1 e aumentando novamente até metade do valor obtido por mecanismo de slow start. A partir de metade o *Additive Increase* passa a ser incremental de uma unidade; 62 | - Por `3 ACKs seguidos`. Ocorre um *Multiplicative Decrease*, passando a Congestion Window a metade e *Additive Increase* passa a ser incremental de uma unidade; -------------------------------------------------------------------------------- /Project2/network/4 - Configure a Commercial Router and Implement NAT.md: -------------------------------------------------------------------------------- 1 | # 2.4 Configure a Commercial Router and Implement NAT 2 | 3 | >## Steps 4 | > 5 | >1. Ligar eth1 do Router à porta 5.1 da régua 6 | > 7 | >2. Ligar eth2 to Router ao Switch 8 | > 9 | >3. Eliminar as portas default do ether5 do switch e ligar o ether5 à bridge51 10 | > 11 | >```bash 12 | > /interface bridge port remove [find interface=ether5] 13 | > /interface bridge port add bridge=bridge51 interface=ether5 14 | >``` 15 | > 16 | >4. Trocar o cabo ligado a consola do Switch para o Router MT 17 | > 18 | >5. No Tux52 conectar ao router desde o GTKterm com: 19 | > 20 | >```note 21 | > Serial Port: /dev/ttyS0 22 | > Baudrate: 115200 23 | > Username: admin 24 | > Password: 25 | >``` 26 | > 27 | >6. Resetar as configuraçoes do router 28 | > 29 | >```bash 30 | > /system reset-configuration 31 | >``` 32 | > 33 | >7. Configurar ip do Router pela consola do router no GTKterm do Tux52 34 | > 35 | >```bash 36 | > /ip address add address=172.16.1.59/24 interface=ether1 37 | > /ip address add address=172.16.51.254/24 interface=ether2 38 | >``` 39 | > 40 | >8. Configurar as rotas default nos Tuxs e no Router: 41 | > 42 | >```bash 43 | > route add default gw 172.16.51.254 # Tux52 44 | > route add default gw 172.16.50.254 # Tux53 45 | > route add default gw 172.16.51.254 # Tux54 46 | > 47 | > /ip route add dst-address=172.16.50.0/24 gateway=172.16.51.253 # Router console 48 | > /ip route add dst-address=0.0.0.0/0 gateway=172.16.1.254 # Router console 49 | >``` 50 | > 51 | >9. No Tux53, começar captura do Wireshark e fazer ping de todas as interfaces. Todas deverão funcionar. Guardar o resultado obtido: 52 | > 53 | >```bash 54 | > ping 172.16.50.254 # Figura 1 55 | > ping 172.16.51.1 # Figura 2 56 | > ping 172.16.51.254 # Figura 3 57 | >``` 58 | > 59 | >10. No Tux52, desativar o *accept_redirects* 60 | > 61 | >```bash 62 | > echo 0 > /proc/sys/net/ipv4/conf/eth0/accept_redirects 63 | > echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects 64 | >``` 65 | > 66 | >11. Remover a rota que liga Tux52 ao Tux54 67 | > 68 | >```bash 69 | > route del -net 172.16.50.0 gw 172.16.51.253 netmask 255.255.255.0 70 | >``` 71 | > 72 | >12. No Tux52, começar captura do wireshark e fazer ping do Tux53. A ligação é estabelecida, usando o Rc como router em vez do Tux54. Comandos: 73 | > 74 | >```bash 75 | > ping 172.16.50.1 # Figura 4 76 | >``` 77 | > 78 | >13. Fazendo traceroute, conseguimos verificar o percurso da ligação 79 | > 80 | >```bash 81 | > traceroute -n 172.16.50.1 82 | > traceroute to 172.16.50.1 (172.16.50.1), 30 hops max, 60 byte packets 83 | > 1 172.16.51.254 (172.16.51.254) 0.200 ms 0.204 ms 0.224 ms 84 | > 2 172.16.51.253 (172.16.51.253) 0.354 ms 0.345 ms 0.344 ms 85 | > 3 tux51 (172.16.50.1) 0.596 ms 0.587 ms 0.575 ms 86 | >``` 87 | > 88 | >14. Adicionar de novo a rota que liga Tux52 ao Tux54 89 | > 90 | >```bash 91 | > route add -net 172.16.50.0/24 gw 172.16.51.253 92 | >``` 93 | > 94 | >15. No Tux52, traceroute para o Tux53 95 | > 96 | >```bash 97 | > traceroute -n 172.16.50.1 98 | > traceroute to 172.16.50.1 (172.16.50.1), 30 hops max, 60 byte packets 99 | > 1 172.16.51.253 (172.16.51.253) 0.196 ms 0.180 ms 0.164 ms 100 | > 2 tux51 (172.16.50.1) 0.414 ms 0.401 ms 0.375 ms 101 | >``` 102 | > 103 | >16. No Tux52, reativar o *accept_redirects* 104 | > 105 | >```bash 106 | > echo 0 > /proc/sys/net/ipv4/conf/eth0/accept_redirects 107 | > echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects 108 | >``` 109 | > 110 | >17. No Tux53, fazer ping do router do lab I.321 para verificar a ligação 111 | > 112 | >```bash 113 | > ping 172.16.1.254 114 | >``` 115 | > 116 | >18. Desativar NAT do Router 117 | > 118 | >```bash 119 | > /ip firewall nat disable 0 120 | >``` 121 | > 122 | >19. No Tux53, fazer de novo ping do router do lab I.321 para verificar a ligação. Verifica-se que não há ligação: 123 | > 124 | >```bash 125 | > ping 172.16.1.254 126 | >``` 127 | > 128 | >20. Reativar Nat do Router 129 | > 130 | >```bash 131 | > /ip firewall nat enable 0 132 | >``` 133 | 134 | ## Questions 135 | 136 | How to configure a static route in a commercial router? 137 | 138 | ```note 139 | Resetar as suas configurações, adicioná-lo à rede interna (à bridge correspondente) e atribuir um IP interno e um IP externo. 140 | ``` 141 | 142 | What are the paths followed by the packets in the experiments carried out and why? 143 | 144 | ```note 145 | Na primeira experiência, sem a ligação do Tux52 ao Tux54, os pacotes de dados foram reencaminhados (ICMP redirect) através do router implementado até ao endereço IP de destino
146 | Já na segunda experiência não houve qualquer reencaminhamento pois a ligação mais curta da rede estava disponível. 147 | ``` 148 | 149 | ![Figura 1 - Ping desde T53](../img/Exp4a.png) 150 | 151 | ![Figura 2 - Ping desde T53](../img/Exp4b.png) 152 | 153 | ![Figura 3 - Ping desde T53](../img/Exp4c.png) 154 | 155 | ![Figura 4 - Redirects](../img/Exp4d.png) 156 | 157 | How to configure NAT in a commercial router? 158 | 159 | ```note 160 | Com o comando `/ip firewall nat enable 0` no terminal do router 161 | ``` 162 | 163 | What does NAT do? 164 | 165 | ```note 166 | O NAT (Network Address Translation) traduz endereços da rede local para um único endereço público, e viceversa. Assim, quando um pacote é enviado para uma rede externa, é enviado com o endereço publico como origem. Quando o computador de destino responde, envia a resposta para esse endereço público, que é depois traduzido de volta para o endereço local de destino que enviou o pacote em primeiro lugar. Deste modo, é possivel reduzir o numero de endereços publicos utilizados. 167 | ``` -------------------------------------------------------------------------------- /Notes/4 - Delay Models.md: -------------------------------------------------------------------------------- 1 | # Delay Models 2 | 3 | ## Multiplexing 4 | 5 | Multiplexar: técnicas para transmitir pacotes de vários tipos num mesmo cabo. Existem três tipos de estratégias 6 | 7 | ### Statistical Multiplexing 8 | 9 | Todos os pacotes de várias proveniências são colocados numa fila de espera. O tempo necessário para transferir os frames é igual ao comprimento dos pacotes / capacidade do canal. 10 | 11 | ### FDM - Frequency Division Multiplexing 12 | 13 | São usadas nas comunicações de rádio. A capacidade do meio é dividida em m subcanais, cada um com a sua frequência. A capacidade de cada canal é C/m e o tempo necessário para transferir os frames é igual a Lm/C. 14 | 15 | ### TDM - Time Division Multiplexing 16 | 17 | O tempo é dividido em m slots com comprimento fixo. Cada pacote é transmitido no seu respectivo tempo, sendo a capacidade do canal a utilizar = C = C/m. Da mesma forma, o tempo necessário para transferir os frames é igual a Lm/C. 18 | 19 | # Queue models 20 | 21 | O delay é um importante indicador de performence nas redes de comunicação. É computado usando modelos de filas de espera, que: 22 | 23 | - Quantificam o número de pacotes na rede; 24 | - Calcula o tempo médio de espera por pacote; 25 | 26 | Quando as filas (nos routers, switches...) estão cheios, há pacotes que se perdem. 27 | 28 | ## Poisson Processes 29 | 30 | Calculam a probabilidade de eventos discretos e independentes: a chegada de x pacotes num intervalo de tempo.
31 | Exemplo: sabe-se que numa rede existe capacidade de transporte de m pacotes por minuto. Calcule a probabilidade de ocorrer transporte de x pacotes nesse mesmo muito. Usando a distribuição de Poisson: 32 | 33 | > P(x) = (m^x * e^(-m)) / x!
34 | > A variância e o valor esperado é sempre igual ao valor médio: m
35 | 36 | Probabilidade do tempo de chegada entre cada pacote ser menor ou igual a A: 37 | 38 | > P(A <=T) = 1 - P(A > T) = 1 - e ^ (-lambda * t)
39 | 40 | Cálculo do tempo médio entre chegadas de pacotes (derivada da fórmula anterior): 41 | 42 | > P() = lambda * e ^ (-lambda * t)
43 | 44 | ### Propriedades do Processo de Poisson 45 | 46 | #### 1. Merging 47 | 48 | O resultado da soma de processos de Poisson continua a ser um processo de Poisson. Exemplo: num local onde chegam 3 pacotes/segundo e 5 pacotes/segundo, origina um fluxo de 8 pacotes/segundo. 49 | 50 | #### 2. Splitting 51 | 52 | O resultado da divisão de processos de Poisson continua a ser um processo de Poisson. Exemplo: num local onde chegam 5 pacotes/segundo, se houver divisão num ramo do fluxo em x pacotes/segundo, o outro ramo terá (5-x) pacotes/segundo. 53 | 54 | ## Caracterização do modelo de filas 55 | 56 | `lambda`: número médio de pacotes enviados por segundo
57 | `pico`: número médio de pacotes processados por segundo
58 | `ró`: lambda / pico, intensidade do tráfico (ocupação do servidor). 59 | 60 | ### Notação de Kendall 61 | 62 | A/S/s/K, onde: 63 | 64 | - A: processo de chegada de pacotes (Poisson, por exemplo) 65 | - S: processo de processamento de pacotes (Poisson, por exemplo) 66 | - s: número de servidores 67 | - K: capacidade do sistema em número de buffers (assumir infinito quando for omido) 68 | 69 | ## Little's Law 70 | 71 | O número médio de pacotes que estão dentro do sistema (N) é igual ao tempo médio em que cada pacote passa no sistema (T) multiplicado pela taxa de chegada de pacotes ao sistema (lambda). 72 | 73 | > N = T * lambda
74 | 75 | Num sistema estável (as filas de espera não crescem infinitamente), o tempo médio de espera não depende da taxa do serviço mas apenas do número de clientes à espera e da taxa de chegada. 76 | 77 | ## Modelo de Markov Chain M/M/1/Inf 78 | 79 | Na Cadeia de Markov, os estados estão numerados de acordo com o número de clientes dentro do sistema. Há uma transição para cada intervalo de tempo delta, em que há possibilidade de avançar no estado (chegou mais um pacote) ou retornar ao estado anterior (o pacote foi processado e saiu do sistema). Assim: 80 | 81 | > P(0, 0), probabilidade de não haver alteração de estado = 1 - lambda*delta - pico*delta
82 | > P(i, i-1), probabilidade do pacote ser processado = pico*delta
83 | > P(i i+1), probabilidade de ter mais um pacote em espera = lambda*delta
84 | > P(0), probabilidade do sistema não ter ninguém = 1 - ró = 1 - probabilidade do sistema estar a processar algo
85 | > P(n), probabilidade do sistema ter X pacotes = ró^n * (1-ró)
86 | 87 | ### Modelos Discretos vs. Modelos Contínuos 88 | 89 | 1. Nos modelos de Poisson de chegada de pacotes, uma taxa de serviço alta não é sinónimo de um número pequeno de pacotes à espera (porque os pacotes tendem a chegar todos juntos); 90 | 91 | 2. Nos modelos discretos de chegada de pacotes (D/D/1), não vai haver espera, considerando um sistema estável (a taxa de chegada <= taxa de processamento); 92 | 93 | ### Modelo M/M/1/B 94 | 95 | Modelo de filas de comprimento finito (B buffers). Neste caso os pacotes podem ser perdidos se os buffers estiverem todos cheios: 96 | 97 | > P(B), probabilidade de perder pelo menos um pacote = ró^B * P(0) 98 | 99 | ### Modelo M/D/1 100 | 101 | Tem um modelo de chegada de pacotes de Poisson, enquanto o tempo de serviço segue uma qualquer distribuição D em que se conheça E[X] e E[X^2]. Assim, segundo a fórmula de Pollaczek-Khinchin (P-K), tem-se que: 102 | 103 | > Tw = lambda * E[X^2] / (2*(1-ró)), com ró = labda / pico = lambda * E[X] 104 | 105 | ## Redes de filas de espera 106 | 107 | Numa rede de X filas de espera, a fila X não poderá ter uma taxa de Poisson chegada de pacotes, uma vez que está limitada à taxa de processamento/serviço da fila X-1. Há, no entanto, duas soluções: 108 | 109 | ### 1. Kleinrock Independence Approximation 110 | 111 | A ideia é acoplar vários envios de pacotes numa mesma linha de transmissão. Assim há reestabelecimento da independência dos tempos segundo os tamanhos dos pacotes. O modelo M/M/1 pode ser usado para modelar cada canal de comunicação.
112 | 113 | - Os sistemas envolvendo Poisson estão nas portas de entrada; 114 | - Os tamanhos dos pacotes são dados por distribuições exponenciais; 115 | - São redes densamente conectadas; 116 | - Moderam a carga de tráfego pesado; 117 | 118 | ### 2. Jakson Networks 119 | 120 | Há uma independência de rotas de pacotes, pois estes ficam em loop no sistema. P(i, j) representa por isso a probabilidade de um pacote sair do nó i e chegar ao nó j, considerando todas as entradas e saídas possíveis entre nós. -------------------------------------------------------------------------------- /Project1/src/application_layer.c: -------------------------------------------------------------------------------- 1 | // Application layer protocol implementation 2 | 3 | #include "application_layer.h" 4 | #include "link_layer.h" 5 | #include 6 | #include 7 | #include 8 | #include 9 | #include 10 | #include 11 | #include 12 | #include 13 | #include 14 | #include 15 | 16 | void applicationLayer(const char *serialPort, const char *role, int baudRate, 17 | int nTries, int timeout, const char *filename) 18 | { 19 | LinkLayer linkLayer; 20 | strcpy(linkLayer.serialPort,serialPort); 21 | linkLayer.role = strcmp(role, "tx") ? LlRx : LlTx; 22 | linkLayer.baudRate = baudRate; 23 | linkLayer.nRetransmissions = nTries; 24 | linkLayer.timeout = timeout; 25 | 26 | int fd = llopen(linkLayer); 27 | if (fd < 0) { 28 | perror("Connection error\n"); 29 | exit(-1); 30 | } 31 | 32 | switch (linkLayer.role) { 33 | 34 | case LlTx: { 35 | 36 | FILE* file = fopen(filename, "rb"); 37 | if (file == NULL) { 38 | perror("File not found\n"); 39 | exit(-1); 40 | } 41 | 42 | int prev = ftell(file); 43 | fseek(file,0L,SEEK_END); 44 | long int fileSize = ftell(file)-prev; 45 | fseek(file,prev,SEEK_SET); 46 | 47 | unsigned int cpSize; 48 | unsigned char *controlPacketStart = getControlPacket(2, filename, fileSize, &cpSize); 49 | if(llwrite(fd, controlPacketStart, cpSize) == -1){ 50 | printf("Exit: error in start packet\n"); 51 | exit(-1); 52 | } 53 | 54 | unsigned char sequence = 0; 55 | unsigned char* content = getData(file, fileSize); 56 | long int bytesLeft = fileSize; 57 | 58 | while (bytesLeft >= 0) { 59 | 60 | int dataSize = bytesLeft > (long int) MAX_PAYLOAD_SIZE ? MAX_PAYLOAD_SIZE : bytesLeft; 61 | unsigned char* data = (unsigned char*) malloc(dataSize); 62 | memcpy(data, content, dataSize); 63 | int packetSize; 64 | unsigned char* packet = getDataPacket(sequence, data, dataSize, &packetSize); 65 | 66 | if(llwrite(fd, packet, packetSize) == -1) { 67 | printf("Exit: error in data packets\n"); 68 | exit(-1); 69 | } 70 | 71 | bytesLeft -= (long int) MAX_PAYLOAD_SIZE; 72 | content += dataSize; 73 | sequence = (sequence + 1) % 255; 74 | } 75 | 76 | unsigned char *controlPacketEnd = getControlPacket(3, filename, fileSize, &cpSize); 77 | if(llwrite(fd, controlPacketEnd, cpSize) == -1) { 78 | printf("Exit: error in end packet\n"); 79 | exit(-1); 80 | } 81 | llclose(fd); 82 | break; 83 | } 84 | 85 | case LlRx: { 86 | 87 | unsigned char *packet = (unsigned char *)malloc(MAX_PAYLOAD_SIZE); 88 | int packetSize = -1; 89 | while ((packetSize = llread(fd, packet)) < 0); 90 | unsigned long int rxFileSize = 0; 91 | unsigned char* name = parseControlPacket(packet, packetSize, &rxFileSize); 92 | 93 | FILE* newFile = fopen((char *) name, "wb+"); 94 | while (1) { 95 | while ((packetSize = llread(fd, packet)) < 0); 96 | if(packetSize == 0) break; 97 | else if(packet[0] != 3){ 98 | unsigned char *buffer = (unsigned char*)malloc(packetSize); 99 | parseDataPacket(packet, packetSize, buffer); 100 | fwrite(buffer, sizeof(unsigned char), packetSize-4, newFile); 101 | free(buffer); 102 | } 103 | else continue; 104 | } 105 | 106 | fclose(newFile); 107 | break; 108 | 109 | default: 110 | exit(-1); 111 | break; 112 | }} 113 | } 114 | 115 | unsigned char* parseControlPacket(unsigned char* packet, int size, unsigned long int *fileSize) { 116 | 117 | // File Size 118 | unsigned char fileSizeNBytes = packet[2]; 119 | unsigned char fileSizeAux[fileSizeNBytes]; 120 | memcpy(fileSizeAux, packet+3, fileSizeNBytes); 121 | for(unsigned int i = 0; i < fileSizeNBytes; i++) 122 | *fileSize |= (fileSizeAux[fileSizeNBytes-i-1] << (8*i)); 123 | 124 | // File Name 125 | unsigned char fileNameNBytes = packet[3+fileSizeNBytes+1]; 126 | unsigned char *name = (unsigned char*)malloc(fileNameNBytes); 127 | memcpy(name, packet+3+fileSizeNBytes+2, fileNameNBytes); 128 | return name; 129 | } 130 | 131 | unsigned char * getControlPacket(const unsigned int c, const char* filename, long int length, unsigned int* size){ 132 | 133 | const int L1 = (int) ceil(log2f((float)length)/8.0); 134 | const int L2 = strlen(filename); 135 | *size = 1+2+L1+2+L2; 136 | unsigned char *packet = (unsigned char*)malloc(*size); 137 | 138 | unsigned int pos = 0; 139 | packet[pos++]=c; 140 | packet[pos++]=0; 141 | packet[pos++]=L1; 142 | 143 | for (unsigned char i = 0 ; i < L1 ; i++) { 144 | packet[2+L1-i] = length & 0xFF; 145 | length >>= 8; 146 | } 147 | pos+=L1; 148 | packet[pos++]=1; 149 | packet[pos++]=L2; 150 | memcpy(packet+pos, filename, L2); 151 | return packet; 152 | } 153 | 154 | unsigned char * getDataPacket(unsigned char sequence, unsigned char *data, int dataSize, int *packetSize){ 155 | 156 | *packetSize = 1 + 1 + 2 + dataSize; 157 | unsigned char* packet = (unsigned char*)malloc(*packetSize); 158 | 159 | packet[0] = 1; 160 | packet[1] = sequence; 161 | packet[2] = dataSize >> 8 & 0xFF; 162 | packet[3] = dataSize & 0xFF; 163 | memcpy(packet+4, data, dataSize); 164 | 165 | return packet; 166 | } 167 | 168 | unsigned char * getData(FILE* fd, long int fileLength) { 169 | unsigned char* content = (unsigned char*)malloc(sizeof(unsigned char) * fileLength); 170 | fread(content, sizeof(unsigned char), fileLength, fd); 171 | return content; 172 | } 173 | 174 | void parseDataPacket(const unsigned char* packet, const unsigned int packetSize, unsigned char* buffer) { 175 | memcpy(buffer,packet+4,packetSize-4); 176 | buffer += packetSize+4; 177 | } -------------------------------------------------------------------------------- /Project1/cable/cable.c: -------------------------------------------------------------------------------- 1 | // Virtual cable program to test serial port. 2 | // Creates a pair of virtual Tx / Rx serial ports using "socat". 3 | // 4 | // Author: Manuel Ricardo [mricardo@fe.up.pt] 5 | // Modified by: Eduardo Nuno Almeida [enalmeida@fe.up.pt] 6 | 7 | #include 8 | #include 9 | #include 10 | #include 11 | #include 12 | #include 13 | #include 14 | #include 15 | 16 | // Baudrate settings are defined in , which is 17 | // included by 18 | #define BAUDRATE B38400 19 | #define _POSIX_SOURCE 1 // POSIX compliant source 20 | #define FALSE 0 21 | #define TRUE 1 22 | 23 | #define BUF_SIZE 2048 24 | 25 | typedef enum 26 | { 27 | CableModeOn, 28 | CableModeOff, 29 | CableModeNoise, 30 | } CableMode; 31 | 32 | // Returns: serial port file descriptor (fd). 33 | int openSerialPort(const char *serialPort, struct termios *oldtio, struct termios *newtio) 34 | { 35 | int fd = open(serialPort, O_RDWR | O_NOCTTY); 36 | 37 | if (fd < 0) 38 | return -1; 39 | 40 | // Save current port settings 41 | if (tcgetattr(fd, oldtio) == -1) 42 | return -1; 43 | 44 | memset(newtio, 0, sizeof(*newtio)); 45 | newtio->c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD; 46 | newtio->c_iflag = IGNPAR; 47 | newtio->c_oflag = 0; 48 | newtio->c_lflag = 0; 49 | newtio->c_cc[VTIME] = 1; // Inter-character timer unused 50 | newtio->c_cc[VMIN] = 0; // Read without blocking 51 | tcflush(fd, TCIOFLUSH); 52 | 53 | if (tcsetattr(fd, TCSANOW, newtio) == -1) 54 | return -1; 55 | 56 | return fd; 57 | } 58 | 59 | // Add noise to a buffer, by flipping the byte in the "errorIndex" position. 60 | void addNoiseToBuffer(unsigned char *buf, size_t errorIndex) 61 | { 62 | buf[errorIndex] ^= 0xFF; 63 | } 64 | 65 | int main(int argc, char *argv[]) 66 | { 67 | printf("\n"); 68 | 69 | system("socat -dd PTY,link=/dev/ttyS10,mode=777 PTY,link=/dev/emulatorTx,mode=777 &"); 70 | sleep(1); 71 | printf("\n"); 72 | 73 | system("socat -dd PTY,link=/dev/ttyS11,mode=777 PTY,link=/dev/emulatorRx,mode=777 &"); 74 | sleep(1); 75 | 76 | printf("\n\n" 77 | "Transmitter must open /dev/ttyS10\n" 78 | "Receiver must open /dev/ttyS11\n" 79 | "\n" 80 | "The cable program is sensible to the following interactive commands:\n" 81 | "--- on : connect the cable and data is exchanged (default state)\n" 82 | "--- off : disconnect the cable disabling data to be exchanged\n" 83 | "--- noise : add fixed noise to the cable\n" 84 | "--- end : terminate the program\n" 85 | "\n"); 86 | 87 | // Configure serial ports 88 | struct termios oldtioTx; 89 | struct termios newtioTx; 90 | 91 | int fdTx = openSerialPort("/dev/emulatorTx", &oldtioTx, &newtioTx); 92 | 93 | if (fdTx < 0) 94 | { 95 | perror("Opening Tx emulator serial port"); 96 | exit(-1); 97 | } 98 | 99 | struct termios oldtioRx; 100 | struct termios newtioRx; 101 | 102 | int fdRx = openSerialPort("/dev/emulatorRx", &oldtioRx, &newtioRx); 103 | 104 | if (fdRx < 0) 105 | { 106 | perror("Opening Rx emulator serial port"); 107 | exit(-1); 108 | } 109 | 110 | // Configure stdin to receive commands to this program 111 | int oldf = fcntl(STDIN_FILENO, F_GETFL, 0); 112 | fcntl(STDIN_FILENO, F_SETFL, oldf | O_NONBLOCK); 113 | 114 | unsigned char tx2rx[BUF_SIZE] = {0}; 115 | unsigned char rx2tx[BUF_SIZE] = {0}; 116 | char rxStdin[BUF_SIZE] = {0}; 117 | 118 | CableMode cableMode = CableModeOn; 119 | volatile int STOP = FALSE; 120 | 121 | printf("Cable ready\n"); 122 | 123 | while (STOP == FALSE) 124 | { 125 | // Read from Tx 126 | int bytesFromTx = read(fdTx, tx2rx, BUF_SIZE); 127 | 128 | if (bytesFromTx > 0) 129 | { 130 | if (cableMode == CableModeOff) 131 | { 132 | printf("bytesFromTx=%d > bytesToRx=CONNECTION OFF\n", bytesFromTx); 133 | } 134 | else 135 | { 136 | if (cableMode == CableModeNoise) 137 | { 138 | addNoiseToBuffer(tx2rx, 0); 139 | } 140 | 141 | int bytesToRx = write(fdRx, tx2rx, bytesFromTx); 142 | printf("bytesFromTx=%d > bytesToRx=%d\n", bytesFromTx, bytesToRx); 143 | //if(bytesFromTx < 30) for(unsigned int i = 0; i < bytesFromTx; i++) printf("%02X ", tx2rx[i]); 144 | //printf("\n"); 145 | } 146 | } 147 | 148 | // Read from Rx 149 | int bytesFromRx = read(fdRx, rx2tx, BUF_SIZE); 150 | 151 | if (bytesFromRx > 0) 152 | { 153 | if (cableMode == CableModeOff) 154 | { 155 | printf("bytesToTx=CONNECTION OFF < bytesFromRx=%d\n", bytesFromRx); 156 | } 157 | else 158 | { 159 | if (cableMode == CableModeNoise) 160 | { 161 | addNoiseToBuffer(rx2tx, 0); 162 | } 163 | 164 | int bytesToTx = write(fdTx, rx2tx, bytesFromRx); 165 | printf("bytesToTx=%d < bytesFromRx=%d\n", bytesToTx, bytesFromRx); 166 | //if(bytesFromRx < 30) for(unsigned int i = 0; i < bytesFromRx; i++) printf("%02X ", rx2tx[i]); 167 | //printf("\n"); 168 | } 169 | } 170 | 171 | // Read commands from STDIN to control the cable mode 172 | int fromStdin = read(STDIN_FILENO, rxStdin, BUF_SIZE); 173 | if (fromStdin > 0) 174 | { 175 | rxStdin[fromStdin - 1] = '\0'; 176 | 177 | if (strcmp(rxStdin, "off") == 0 || strcmp(rxStdin, "0") == 0) 178 | { 179 | printf("CONNECTION OFF\n"); 180 | cableMode = CableModeOff; 181 | } 182 | else if (strcmp(rxStdin, "on") == 0 || strcmp(rxStdin, "1") == 0) 183 | { 184 | printf("CONNECTION ON\n"); 185 | cableMode = CableModeOn; 186 | } 187 | else if (strcmp(rxStdin, "noise") == 0 || strcmp(rxStdin, "2") == 0) 188 | { 189 | printf("CONNECTION NOISE\n"); 190 | cableMode = CableModeNoise; 191 | } 192 | else if (strcmp(rxStdin, "end") == 0) 193 | { 194 | printf("END OF THE PROGRAM\n"); 195 | STOP = TRUE; 196 | } 197 | } 198 | } 199 | 200 | // Restore the old port settings 201 | if (tcsetattr(fdRx, TCSANOW, &oldtioRx) == -1) 202 | { 203 | perror("tcsetattr"); 204 | exit(-1); 205 | } 206 | 207 | if (tcsetattr(fdTx, TCSANOW, &oldtioTx) == -1) 208 | { 209 | perror("tcsetattr"); 210 | exit(-1); 211 | } 212 | 213 | close(fdTx); 214 | close(fdRx); 215 | 216 | system("killall socat"); 217 | 218 | return 0; 219 | } 220 | -------------------------------------------------------------------------------- /Project2/src/download.c: -------------------------------------------------------------------------------- 1 | #include "../include/download.h" 2 | 3 | int parse(char *input, struct URL *url) { 4 | 5 | regex_t regex; 6 | regcomp(®ex, BAR, 0); 7 | if (regexec(®ex, input, 0, NULL, 0)) return -1; 8 | 9 | regcomp(®ex, AT, 0); 10 | if (regexec(®ex, input, 0, NULL, 0) != 0) { //ftp:/// 11 | 12 | sscanf(input, HOST_REGEX, url->host); 13 | strcpy(url->user, DEFAULT_USER); 14 | strcpy(url->password, DEFAULT_PASSWORD); 15 | 16 | } else { // ftp://[:@]/ 17 | 18 | sscanf(input, HOST_AT_REGEX, url->host); 19 | sscanf(input, USER_REGEX, url->user); 20 | sscanf(input, PASS_REGEX, url->password); 21 | } 22 | 23 | sscanf(input, RESOURCE_REGEX, url->resource); 24 | strcpy(url->file, strrchr(input, '/') + 1); 25 | 26 | struct hostent *h; 27 | if (strlen(url->host) == 0) return -1; 28 | if ((h = gethostbyname(url->host)) == NULL) { 29 | printf("Invalid hostname '%s'\n", url->host); 30 | exit(-1); 31 | } 32 | strcpy(url->ip, inet_ntoa(*((struct in_addr *) h->h_addr))); 33 | 34 | return !(strlen(url->host) && strlen(url->user) && 35 | strlen(url->password) && strlen(url->resource) && strlen(url->file)); 36 | } 37 | 38 | int createSocket(char *ip, int port) { 39 | 40 | int sockfd; 41 | struct sockaddr_in server_addr; 42 | 43 | bzero((char *) &server_addr, sizeof(server_addr)); 44 | server_addr.sin_family = AF_INET; 45 | server_addr.sin_addr.s_addr = inet_addr(ip); 46 | server_addr.sin_port = htons(port); 47 | 48 | if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { 49 | perror("socket()"); 50 | exit(-1); 51 | } 52 | if (connect(sockfd, (struct sockaddr *) &server_addr, sizeof(server_addr)) < 0) { 53 | perror("connect()"); 54 | exit(-1); 55 | } 56 | 57 | return sockfd; 58 | } 59 | 60 | int authConn(const int socket, const char* user, const char* pass) { 61 | 62 | char userCommand[5+strlen(user)+1]; sprintf(userCommand, "user %s\n", user); 63 | char passCommand[5+strlen(pass)+1]; sprintf(passCommand, "pass %s\n", pass); 64 | char answer[MAX_LENGTH]; 65 | 66 | write(socket, userCommand, strlen(userCommand)); 67 | if (readResponse(socket, answer) != SV_READY4PASS) { 68 | printf("Unknown user '%s'. Abort.\n", user); 69 | exit(-1); 70 | } 71 | 72 | write(socket, passCommand, strlen(passCommand)); 73 | return readResponse(socket, answer); 74 | } 75 | 76 | int passiveMode(const int socket, char *ip, int *port) { 77 | 78 | char answer[MAX_LENGTH]; 79 | int ip1, ip2, ip3, ip4, port1, port2; 80 | write(socket, "pasv\n", 5); 81 | if (readResponse(socket, answer) != SV_PASSIVE) return -1; 82 | 83 | sscanf(answer, PASSIVE_REGEX, &ip1, &ip2, &ip3, &ip4, &port1, &port2); 84 | *port = port1 * 256 + port2; 85 | sprintf(ip, "%d.%d.%d.%d", ip1, ip2, ip3, ip4); 86 | 87 | return SV_PASSIVE; 88 | } 89 | 90 | int readResponse(const int socket, char* buffer) { 91 | 92 | char byte; 93 | int index = 0, responseCode; 94 | ResponseState state = START; 95 | memset(buffer, 0, MAX_LENGTH); 96 | 97 | while (state != END) { 98 | 99 | read(socket, &byte, 1); 100 | switch (state) { 101 | case START: 102 | if (byte == ' ') state = SINGLE; 103 | else if (byte == '-') state = MULTIPLE; 104 | else if (byte == '\n') state = END; 105 | else buffer[index++] = byte; 106 | break; 107 | case SINGLE: 108 | if (byte == '\n') state = END; 109 | else buffer[index++] = byte; 110 | break; 111 | case MULTIPLE: 112 | if (byte == '\n') { 113 | memset(buffer, 0, MAX_LENGTH); 114 | state = START; 115 | index = 0; 116 | } 117 | else buffer[index++] = byte; 118 | break; 119 | case END: 120 | break; 121 | default: 122 | break; 123 | } 124 | } 125 | 126 | sscanf(buffer, RESPCODE_REGEX, &responseCode); 127 | return responseCode; 128 | } 129 | 130 | int requestResource(const int socket, char *resource) { 131 | 132 | char fileCommand[5+strlen(resource)+1], answer[MAX_LENGTH]; 133 | sprintf(fileCommand, "retr %s\n", resource); 134 | write(socket, fileCommand, sizeof(fileCommand)); 135 | return readResponse(socket, answer); 136 | } 137 | 138 | int getResource(const int socketA, const int socketB, char *filename) { 139 | 140 | FILE *fd = fopen(filename, "wb"); 141 | if (fd == NULL) { 142 | printf("Error opening or creating file '%s'\n", filename); 143 | exit(-1); 144 | } 145 | 146 | char buffer[MAX_LENGTH]; 147 | int bytes; 148 | do { 149 | bytes = read(socketB, buffer, MAX_LENGTH); 150 | if (fwrite(buffer, bytes, 1, fd) < 0) return -1; 151 | } while (bytes); 152 | fclose(fd); 153 | 154 | return readResponse(socketA, buffer); 155 | } 156 | 157 | int closeConnection(const int socketA, const int socketB) { 158 | 159 | char answer[MAX_LENGTH]; 160 | write(socketA, "quit\n", 5); 161 | if(readResponse(socketA, answer) != SV_GOODBYE) return -1; 162 | return close(socketA) || close(socketB); 163 | } 164 | 165 | int main(int argc, char *argv[]) { 166 | 167 | if (argc != 2) { 168 | printf("Usage: ./download ftp://[:@]/\n"); 169 | exit(-1); 170 | } 171 | 172 | struct URL url; 173 | memset(&url, 0, sizeof(url)); 174 | if (parse(argv[1], &url) != 0) { 175 | printf("Parse error. Usage: ./download ftp://[:@]/\n"); 176 | exit(-1); 177 | } 178 | 179 | printf("Host: %s\nResource: %s\nFile: %s\nUser: %s\nPassword: %s\nIP Address: %s\n", url.host, url.resource, url.file, url.user, url.password, url.ip); 180 | 181 | char answer[MAX_LENGTH]; 182 | int socketA = createSocket(url.ip, FTP_PORT); 183 | if (socketA < 0 || readResponse(socketA, answer) != SV_READY4AUTH) { 184 | printf("Socket to '%s' and port %d failed\n", url.ip, FTP_PORT); 185 | exit(-1); 186 | } 187 | 188 | if (authConn(socketA, url.user, url.password) != SV_LOGINSUCCESS) { 189 | printf("Authentication failed with username = '%s' and password = '%s'.\n", url.user, url.password); 190 | exit(-1); 191 | } 192 | 193 | int port; 194 | char ip[MAX_LENGTH]; 195 | if (passiveMode(socketA, ip, &port) != SV_PASSIVE) { 196 | printf("Passive mode failed\n"); 197 | exit(-1); 198 | } 199 | 200 | int socketB = createSocket(ip, port); 201 | if (socketB < 0) { 202 | printf("Socket to '%s:%d' failed\n", ip, port); 203 | exit(-1); 204 | } 205 | 206 | if (requestResource(socketA, url.resource) != SV_READY4TRANSFER) { 207 | printf("Unknown resouce '%s' in '%s:%d'\n", url.resource, ip, port); 208 | exit(-1); 209 | } 210 | 211 | if (getResource(socketA, socketB, url.file) != SV_TRANSFER_COMPLETE) { 212 | printf("Error transfering file '%s' from '%s:%d'\n", url.file, ip, port); 213 | exit(-1); 214 | } 215 | 216 | if (closeConnection(socketA, socketB) != 0) { 217 | printf("Sockets close error\n"); 218 | exit(-1); 219 | } 220 | 221 | return 0; 222 | } 223 | -------------------------------------------------------------------------------- /Notes/5 - MAC.md: -------------------------------------------------------------------------------- 1 | # 5 - Medium Access Control 2 | 3 | A Data Link Layer subdivide-se em duas camadas: a LLC (Logical Link Control) e MAC (Medium Access Control). 4 | 5 | - `LLC` é faz a interface entre a Network Layer e é responsável pelo fluxo de dados e deteção de erros; 6 | - `MAC` é responsável pelo controlo de acesso, recepção e retransmissão de erros, endereços e deteção de erros. 7 | 8 | ## Tipos de meios de comunicação 9 | 10 | - `Point-to-Point`, entre o Switch da internet e o host; 11 | - `Broadcast`, entre meios partilhados, como ligações por cabo em redes, satélite e wifi; 12 | 13 | ## Coordenação de estações com broadcast e meio partilhado 14 | 15 | Numa situação normal, vários são os computadores que comunicam usando o mesmo canal. Existindo m estações e o canal com capacidade R bits/s: 16 | 17 | > numa situação em que só um comunica e todos lêm a velocidade é R bits/s,
18 | > numa situação em que vários tentam comunicar, em média a velocidade é R/m bits/s
19 | 20 | ## Classes de protocolos MAC 21 | 22 | ### Channel Partitioning 23 | 24 | - `TDMA Time Division Multiple Access`, o tempo é dividido em m porções; 25 | - `FDMA Frequency Division Multiple Access`, a frequência é dividida em m porções; 26 | 27 | ### Random Access Protocols 28 | 29 | Assumindo que não há coordenação entre estações e o canal disponível transmite R bits/s. Se duas ou mais transmitem no canal ao mesmo tempo, existe uma **colisão**: a mensagem perde-se pelo ruído causado (os receptores só têm acesso ao somatório das frequências transmitidas) e tem de haver retransmissão de cada uma. 30 | 31 | - Quando a transmissão pode ocorrer? 32 | - Como detectar colisões (na parte do receptor e transmissor); 33 | - Se houver colisões, como recuperar os dados? 34 | 35 | #### ALOHA 36 | 37 | ##### Funcionamento 38 | 39 | Implementação simples e descentralizada em cada estação. Sempre que uma estação tem um pacote para enviar, envia imediatamente e fica em espera da confirmação até receber uma confirmação. Se não receber confirmação, parte do princípio que houve colisão e nesse caso espera um tempo aleatório K até à próxima retransmissão. O tempo aleatório K é importante porque se houve realmente colisão e houver uma retransmissão imediata, há muita probabilidade de ocorrer novamente. 40 | 41 | ##### Eficiência 42 | 43 | A implementação desta técnica com slots de tempo é mais eficiente (36.8% contra 18.4%, considerando a probabilidade de uma estação gerar um pacote = 100%). 44 | 45 | Quando o tráfego é residual, a técnica ALOHA é bastante requisitada, pois em média há espera de 0.5 slots de tempo. Quando o tráfego é intenso, o tempo de espera aumenta exponencialmente, pois a probabilidade de colisão é elevada e aumenta o número de retransmissões. 46 | 47 | #### CSMA Carrier Sense Multiple Access 48 | 49 | ##### Funcionamento 50 | 51 | Cada estação não interrompe a transmissão de outras. No entanto as colisões ainda podem ocorrer devido aos tempos de propagação pelo canal, causando perda integral do pacote transmitido. 52 | 53 | ##### Eficiência 54 | 55 | É uma técnica usada para valores de `a` bastante baixo, ou seja, a probabilidade de haver colisões é também baixa. 56 | 57 | > a = Tempo de propagação / Tempo de transmissão do pacote 58 | 59 | ##### Persistent CSMA 60 | 61 | A estação transmite quando o canal estiver disponível. Quando o canal não estiver livre, então espera até que esteja. É o subtipo mais utilizado. 62 | 63 | ##### Non-Persistent CSMA 64 | 65 | A estação transmite quando o canal estiver disponível. Quando o canal não estiver livre, então espera um tempo random e retransmite. É menos eficiente. 66 | 67 | ##### P-Persistent CSMA 68 | 69 | É um intermédio entre os dois tipos anteriores. A estação transmite pacotes com probabilidade p. É considerado colisão quando a transmissão não ocorreu bem no slot anterior, caso contrário a estação espera até que a estação esteja livre e aí repete o algoritmo. 70 | 71 | #### CSMA/CD Carrier Sense Multiple Access Collision Detection 72 | 73 | ##### Funcionamento 74 | 75 | Semelhante à técnica de CSMA. Enquanto uma estação transmite, fica à escuta. Se ouvir algo diferente do que transmite, então existe colisão e aborta imediatamente a operação. Assim não é necessário haver resposta para transmissões bem sucedidas (ACK). 76 | 77 | Para uma retransmissão, determina um atraso aleatório usando um algoritmo chamado "Binary Exponential Backoff". Para a retransmissão i, espera-se um número de slots aleatórios na gama [0, 2^i-1]. 78 | 79 | Tramas curtas podem impedir a deteção de colisões sob o ponto de vista do emissor. O tempo de transmissão da trama deve ser maior do que duas vezes o tempo de ida e volta (tempo de propagação). 80 | 81 | ##### Eficiência 82 | 83 | > a = Tempo de propagação máximo / Tempo de transmissão da trama
84 | > S = eficiência = 1 / (1 + 2ea) = 1 / (1 + 5.44a)
85 | 86 | Esta técnica é bastante eficiente (S aproximado a 1) quando: 87 | 88 | - o cabo é pequeno; 89 | - comprimento das tramas é grande 90 | 91 | Na prática por causa de FER (*Frame Error Ratio*) a trama não pode ser muito grande. Não pode ser usado em meios sem fios uma vez que a atenuação é elevada: neste caso o transmissor ouve aquilo que fiz com uma potência elevada, a potência do outro transmissor é ouvida numa percentagem muito baixa e assim pode não haver deteção de colisões. 92 | 93 | #### CSMA/CA Carrier Sense Multiple Access Collision Avoidance 94 | 95 | ##### Funcionamento 96 | 97 | Semelhante à técnica de CSMA. Antes de transmitir, a estação fica à escuta DIFS tempo e se o meio ainda estiver livre ao fim desse tempo, transmite o pacote. Senão, espera até à transmissão da estação e volta a esperar DIFS tempo mais um tempo aleatório com Backoff até tentar novamente. Para evitar colisões é necessário voltar a existir pacotes de confirmação (ACK). 98 | 99 | É um protocolo usado nas redes sem fios. 100 | 101 | ##### CSMA/CA RTS-CTS 102 | 103 | Como as colisões não são detectadas e frames abortados, então há pequenos frames reservados usados para requests: 104 | 105 | - RTS: Request to Send, como pedido 106 | - CTS: Clear to Send, como resposta, é ouvida por todas as estações para evitar colisões. 107 | 108 | ### Taking turns 109 | 110 | #### Polling 111 | 112 | A estação principal dá autorização a outras estações para transmitir no seu tempo. Se os tempos forem bem implementados, não há colisões mas há algum tempo perdido em espera e na transmissão dos pedidos. 113 | 114 | #### Token passing 115 | 116 | Só há transmissão de dados nas estações que têm token. Pelo lado negativo há latência pois embora haja estações em que não têm nada a transmitir na sua vez, têm de passar o token pela rede e isso demora tempo. 117 | 118 | ## Ethernet Topology 119 | 120 | 1. `Bus` - com cabo coaxial, os computadores ligavam-se através de um cabo onde podia haver colisões e múltiplos transmissores e receptores. 121 | 2. `Active Hub` - existem repetidores que enviam os bits recebidos para todos as outras portas. Existe deteção de colisão, mas só numa única porta de cada vez. 122 | 3. `Bridge` - Separa os domínios de colisão e vários frames podem ser transmitidos simultaneamente. 123 | 4. `Full Duplex Ethernet` - o CSMA/CD não é usado praticamente, pois não existem colisões. Os cabos UTP são usados (Unshielded Twisted Pair), que são mais baratos e fáceis de instalar, embora não suportem bem múltiplas transmissões ou receptores; 124 | 5. `Ethernet de hoje em dia` - UTP para distâncias curtas, fibras óticas para longas, suporta redundância para minimizar erros. 125 | 126 | ### Switch Self-Learning 127 | 128 | As tramas que vão chegando ao switch, tem endereço de origem e destino. À medida que transmite e recebe, vai preenchendo as tabelas que relacionam os computadores às portas (se o computador A mandou informação na porta 1, então para comunicar com A é necessário enviar tramas na porta 1). As tabelas são temporárias e se o switch não souber para onde enviar, envia para todas as portas excepto ao transmissor. 129 | 130 | ### Virtual LANs 131 | 132 | Quando uma bridge ou switch tem simultaneamente várias redes, vários domínios de colisão. Podem ser extendidas com interfaces/cabos de fibra ótica *trunk link*. -------------------------------------------------------------------------------- /Notes/6 - Network Layer.md: -------------------------------------------------------------------------------- 1 | # 6 - Network Layer 2 | 3 | A camada de rede (a terceira camada) tem como funções principais: 4 | 5 | - **transportar pacotes** desde a origem até ao destino; 6 | - **cálculo dos caminhos** através de grafos, para mandar os pacotes a passar pelo mínimo número de componentes da rede possível; 7 | 8 | ## Virtual Circuits and Datagram Networks 9 | 10 | ### VC - Virtual Circuits 11 | 12 | Criação do circuito virtual entre o primeiro router e o último router para transferência de dados. Para isso há estabelecimento de um conjunto de identificadores virtuais, presentes numa tabela. Só depois do caminho estabelecido é que há transferência contínua e sequencial de todos os pacotes e durante isso não há utilização do mesmo circuito por parte de outros pacotes. É, por isso, mais fácil de gerir. 13 | 14 | ### Datagrams Networks 15 | 16 | Não é necessário estabelecer o caminho antes da transferência. Cada um dos pacotes vai ser encaminhado independentemente, possivelmente fora de ordem. Não há garantias da qualidade de serviço ou do controlo de congestionamento. 17 | 18 | ## Internet Protocol (IP) 19 | 20 | Na Network Layer temos três tipos de protocolos: 21 | 22 | - IP Protocol, que garante as convenções de endereçamento, o formato das tramas e a recepção dos pacotes; 23 | - ICMP protocol, que garante o report dos erros; 24 | - Routing protocol, que garante a escolha do melhor caminho para enviar a informação entre os routers (RIP, OSPF, BGP); 25 | 26 | ### IP Datagram Format 27 | 28 | Na trama de dados é indicada: 29 | - a versão do protocolo; 30 | - o tamanho do header; 31 | - o tamanho da zona dos dados; 32 | - tempo de vida, ou seja, o número máximo de routers a visitar. Isto permite descartar pacotes que estejam em ciclos infinitos na rede; 33 | - checksum do header; 34 | - endereço IP da origem e do destino, ambos com 32 bits; 35 | 36 | ### Fragmentação e Reassemblagem 37 | 38 | Nas redes podem existir links que tenham MTU (maximum transfer size), o que impossibilita o envio de pacotes que excedam esse tamanho. Assim, é necessário fazer `fragmentação` do pacote em subpacotes. No destino, existe a `reassemblagem`, que constroi o pacote original. 39 | 40 | Na fragmentação, todos os subpacotes excepto o último contêm uma flag de fragmento = 1. Têm também um offset, que é igual ao número de bytes de informação que ainda restam (número de bits / 8). 41 | 42 | ### Endereços IP 43 | 44 | São endereços de 32, representados com 4 números em decimal (exemplo: 127.0.0.1). Cada mecanismo da rede tem o seu endereço IP único. 45 | 46 | #### CIDR - Classless InterDomain Routing 47 | 48 | Cada subrede tem o endereço de rede (os três primeiros números decimais, os 24 bits mais significativos) iguais. Assim, os 8 bits menos significativos são diferentes para cada computador. Computadores que estão na mesma subrede podem comunicar entre si sem necessário ter a interferência de um router a encaminhar os pacotes. 49 | 50 | 127.34.19.0/23, significa que o IP da subrede é definido pelos 23 bits mais significativos. 51 | 52 | ### Subnetting 53 | 54 | Há possibilidade de definir uma subrede dentro de uma rede. Para isso utiliza-se uma máscara de X bits. Exemplo: subnetid de 3 bits e hostid de 5 bits numa rede 192.228.17.0/24. 55 | 56 | #### Endereços IP especiais 57 | 58 | 0.0.0.0 - o computador está a enviar o pacote para ele mesmo 59 | 0.0.0.X - o computador está a enviar o pacote para um computador X na mesma rede 60 | 255.255.255.255 - para enviar o pacote a todos os membros da rede local (broadcast) 61 | network.255.255.255 - para enviar o pacote a todos os membros da rede destino 62 | 127.X.X.X - para um computador enviar pacotes para ele mesmo, loopback 63 | 64 | ##### Nota 65 | 66 | Apesar de existirem X bits disponíveis para endereçar, há apenas 2^X-2 endereços disponíveis (não considerar tudo 0, subnet, ou tudo 1, broadcast). 67 | 68 | ### Encaminhamento de pacotes 69 | 70 | Quando o router recebe um pacote na porta de entrada, consulta uma tabela "Forwarding table": cada destino está associado à interface/porta correspondente do router mais próximo na rede. 71 | 72 | Uma tabela que tenha o prefixo da network (123.234.122.201), a máscara (/24), o gateway (123.123.125.123) e a interface (ethX), então: 73 | - Se o resultado da máscara & prefixo da network for igual, adicionar ao conjunto; 74 | - Escolher do conjunto o que contém a maior máscara, ou seja, o que tem encaminhamento mais específico; 75 | - Se a entrada selecionada tiver um gateway, então enviar para ele a partir da interface especificada; 76 | - Caso contrário, enviar logo para o computador de destino final; 77 | 78 | ### Address Resolution Protocol ARP 79 | 80 | Usado para obter o MAC address de algum computador na rede e associá-lo ao seu endereço IP. O IP e MAC do computador de origem é partilhado na rede por todos (broadcast) assim como o IP desconhecido. O computador que tiver o IP responderá com o seu endereço MAC e assim poderá haver conexão e transferência entre os dois. 81 | 82 | #### Funcionamento 83 | 84 | Considerando: 85 | - ID - ip de destino 86 | - IO - ip de origem 87 | - MD - mac address de destino 88 | - MO - mac address de origem 89 | 90 | A trama de informação entre um computador A, um router R e um computador B: 91 | - Entre A e R terá ID = B, IO = A, MD = R, MO = A 92 | - Entre R e B terá ID = B, IO = A, MD = B, MO = R 93 | 94 | ### Obtenção de endereços IP, protocolo DHCP 95 | 96 | Através dos ISPs. Para servidores HTTP ou de email os IPs são fixos, para outros casos (máquinas pessoais) usa-se o protocolo DHCP (*Dynamic Host Configuration Protocol*). Funcionamento entre servidor-cliente (DORA): 97 | - O computador que chega à rede manda um DHCP discover ao servidor; 98 | - O servidor retorna um DHCP offer 99 | - O computador responde com DHCP request; 100 | - O servidor retorna um DHCP Ack; 101 | Cada transação contém um ID, que é diferente para cada computador da rede. 102 | 103 | ### Network Address Translation (NAT) 104 | 105 | Inicialmente o IPv4 continha apenas 32 bits, o que não foi suficiente para o crescimento da internet. Atualmente existe o IPv6. NAT veio como uma solução para a falta de endereços: existem endereços de formatos que não são usados na internet, não são alcançáveis, pois existe sobreposição. Todos os requests da rede local são enviados com o IP do router, que contém um endereço único. O router contém uma tabela NAT que associa o endereço de origem ao endereço de destino, podendo fazer a tradução quando a resposta chega. 106 | 107 | #### NAT Transversal 108 | 109 | Um servidor na rede local (com IP que pode ser comum a muitas redes) pode-se ligar ao exterior através de uma porta fixa X. Assim, todos os requests que vêm para a rede local, o router encaminha diretamente para o servidor assinalado. 110 | 111 | ## Internet Control Message Protocol (ICMP) 112 | 113 | Usada por routers e servidores host. Consistem em mensagens especiais para avisar de algum erro ou mensagens de controlo. Permitem inclusive fazer o **redirect** de pacotes quando um servidor/router X perceber que o percurso é mais curto de outro lado. 114 | 115 | ### Comandos 116 | 117 | ```bash 118 | $ ping # manda mensagens/pacotes para atribuir estatísticas ao servidor de destino 119 | $ traceroute # manda mensagens com time = 1,2,3... de forma a traçar o percurso dos dados 120 | $ netstat -nr # permite ver a forwarding table, com destination, gateway, genmask... 121 | $ ip rout show cache # ver a cache do ip atual 122 | ``` 123 | 124 | ## IPv6 125 | 126 | - Os endereços são de 128 bits e normalmente representados em hexadecimal; 127 | - Melhorias no suporte a multicast 128 | - Configurações de host; 129 | - Mais eficiente em routing 130 | - Os endereços com zeros podem ser abreviados (::) mas só uma vez por motivos de ambiguidade; 131 | - Os endereços IPv4 podem ser convertidos: ::ffff:5.6.7.8 132 | 133 | ### Endereços IPv6 134 | 135 | #### Link Local 136 | 137 | Usado para comunicar entre hosts dentro da mesma LAN. É criado automaticamente pelo MAC address. Os routers não reencaminham pacotes com endereço de destino Link Local. Formato: fe08::/10 138 | 139 | #### Global Unicast 140 | 141 | Pode ser gerado automaticamente pelo prefixo e o MAC address e são os endereços globais da internet. Formato: 2000::/3 142 | 143 | #### Anycast 144 | 145 | Atribuído a vários dispositivos e um pacote é recebido por um qualquer (e apenas um) deles. Formato: prefixo da subnet:: (128-n bits a zero). 146 | 147 | #### Multicast 148 | 149 | É um endereço para um grupo que tem escopo de link, site ou global. Todos os dispositivos dentro do mesmo grupo recebem o pacote. Formato: 8 1's, flag, escopo e o ID do grupo. 150 | 151 | ### Protocol Neighbor Discovery (ND) 152 | 153 | O IPv6 usa este protocolo para: 154 | 155 | - descobrir os nós do mesmo LAN; 156 | - descobrir os vizinhos de um MAC address a partir dos seus endereços IPv6; 157 | - encontrar rotas na rede; 158 | - manter a informação dos seus vizinhos; 159 | 160 | As mensagens possíveis são as seguintes, que são obtidas através de endereços Link Local: 161 | 162 | - `Neighbor solicitation`, para obter o endereço MAC do vizinho ou saber se ele está presente; 163 | - `Neighbor advertisement`, resposta à solicitação; 164 | - `Router advertisement`, usado pelos routers para enviar informação sobre o prefixo da rede; 165 | - `Router solicitation`, request de um router advertisement de um router no link; 166 | - `Redirect`, para informar um host sobre a melhor rota a tomar; -------------------------------------------------------------------------------- /Notes/3 - Data Link Layer.md: -------------------------------------------------------------------------------- 1 | # Data Link layer 2 | 3 | É a camada que permite a comunicação entre máquinas adjacentes. O seu objectivo é reduzir e eliminar os erros de transmissão que podem ocorrer na physical layer e regular o fluxo de dados. 4 | 5 | ## Framing 6 | 7 | Os dados enviados devem ser separados em frames / pacotes para regular o fluxo de dados e reduzir a possibilidade de erros, com posterior retransmissão caso ocorram. Para isso há três técnicas que são usadas: 8 | 9 | ### 1 - Character byte count 10 | 11 | O primeiro byte do frame indica quantos bytes o frame possui. No entanto, quando ocorre um erro torna-se impossível resolver a situação e a partir daí todos os dados são corrompidos. Não é uma técnica usada atualmente. 12 | 13 | ### 2 - Flag bytes with byte stuffing 14 | 15 | O frame é delimitado por bytes de flag. Como o código desses bytes pode aparecer no meio dos dados, ocorrendo assim o possível corte da frame e consequente perda de dados, então há o **byte stuffing**: antes de cada flag que apareça nos dados, colocar um byte de escape ESC, até mesmo para o próprio byte de ESC. O receptor, antes de qualquer análise aos dados do frame, deverá fazer destuffing. É esta técnica a adoptar no caso do trabalho prático. 16 | 17 | ### 3 - Start and End flags with bit stuffing 18 | 19 | Em vez de criar um byte, coloca-se um bit para travar qualquer interpretação errada. Por exemplo: se a flag for 0b01111110, então nos dados depois de cada 011111 colocar um 0 para evitar sequências iguais. De forma semelhante, o receptor só deverá interpretar os dados quando ocorrer destuffing. 20 | 21 | ## Error detection 22 | 23 | Pode haver erros de um bit transmitido (*simple error*) ou de um grupo de bits transmitidos (*errors in bursts*). Estes últimos não são independentes e afetam os bits vizinhos. 24 | 25 | ### Probabilidades 26 | 27 | - A probabilidade de um frame não conter erros, FER (Frame Error Ratio), é dado por FER = (1-BER)^n, com BER igual à probabilidade de um bit ter erros de transmissão (Bit Error Ratio) e n o comprimento do frame enviado. 28 | 29 | - A probabilidade de i bits conterem erros é igual à quantidade de escolhas possíveis nos n bits da trama vezes a probabilidade de n-i bits serem transmitidos bem e i bits serem transmitidos erradamente, com i <= n. 30 | 31 | ## Error technics 32 | 33 | Nestes casos seguintes: 34 | - `d`, significa o número de bits mínimo para que um erro não seja detectado num conjunto de dados transmitido; 35 | - `D`, significa o número máximo de erros detectados num conjunto de bits; 36 | 37 | ### Redundância 38 | 39 | Em vez de enviar um frame de k bits, envia um frame de k+r bits, com r a servir de redundância. Assim, do lado do receptor, pode haver um reconhecimento de um erro ocorrido num ou mais dos k bits de dados. 40 | 41 | #### Simple Parity Check 42 | 43 | - Paridade par: verifica se o número de bits a 1 é par; 44 | - Paridade ímpar: verifica se o número de bits a 1 é ímpar; 45 | 46 | Nesta situação, apenas detecta erros simples ou erros derivados de um número ímpar de erros de transmissão. É muito usado em protocolos orientados a caracteres. 47 | 48 | #### Bi-dimensional Parity Check 49 | 50 | Parecido com a situação anterior, mas a paridade é calculada por bloco, em linhas verticais e horizontais. Neste caso, qualquer erro numa configuração rectangular é indetectável, ou seja, d = 4. 51 | 52 | #### Cyclic Redundancy Check 53 | 54 | A string de bits é representada por um polinómio M(x). Quando o número de bits em redundância é r, escolhemos uma string G(x) = x^r + 1 (r=3, s=1001), e fazemos uma divisão inteira de M(x) * x^r pelo polinómio G(x), que dará um polinómio R(x). O transmitido deverá ser M(x)*x^r + R(x).
55 | No lado do receptor, é só fazer a divisão inteira de T(x) por G(x). Se R(x) for diferente de zero, então algum erro ocorreu. 56 | 57 | É uma técnica muito usada, principalmente por ser facilmente implementada em software. Consegue detectar qualquer conjunto de 1,2 ou 3 erros (d > 3), todos os conjuntos com r ou menos bits e todos os erros que consistem num número ímpar de bits invertidos. 58 | 59 | ## Automatic Repeat Request (ARQ) 60 | 61 | Sistema que pede retransmissões de pacotes em falta ou com erros detectados. Existem três técnicas principais: 62 | 63 | ### 1 - Stop and Wait 64 | 65 | O transmissor lança uma frame I e espera até que exista confirmação (ACK) do lado do receptor. Quando o receptor recebe o frame I, se este tiver erros lança um NACK, senão lança um ACK. Do outro lado é necessário existir um timeout e um número de tentativas fixas para prevenir erros de transmissão de mensagens. Caso receba um NACK, volta a enviar o frame anterior. 66 | 67 | #### Problema 68 | 69 | Necessita de um conjunto sequencial de frames numerados, caso contrário os timeouts de um lado e do outro acabam por baralhar a transmissão. Neste caso apenas existem ACK(i) e o NACK não é necessário. 70 | 71 | #### Eficiência 72 | 73 | ##### Sem erros 74 | 75 | A eficiência mede-se através da razão entre o tempo de manipulação do frame por parte do receptor, Tf, e a soma entre Tf e os tempos de propagação, Tp. Ou seja, segundo esta fórmula: 76 | 77 | > S = Tf / (Tf + 2*Tp) 78 | 79 | ##### Com erros 80 | 81 | Designando pe pela probabilidade de ocorrência de um erro no frame, então a eficiência é dada pela seguinte fórmula: 82 | 83 | > S = (1 - pe) / (Tf + 2*Tp) 84 | 85 | ### 2 - Go Back N 86 | 87 | O problema do protocolo Stop and Wait é que em para longas distâncias, o tempo de transmissão é cada vez maior e acaba por diminuir bastante a eficiência. A ideia agora é estudar os `sliding window protocols`: permitem a transmissão de vários frames antes de começar a receber as confirmações do seu envio. 88 | 89 | #### Transmissor 90 | 91 | Pode transmitir W frames (W = 2^k-1, com k a ser o número de bits usados para codificar as sequências) e tem de esperar por alguma confirmação antes de transmitir o W+1 frame. 92 | Se um timeout ocorrer, o transmissor envia uma mensagem RR() para que o receptor indique qual é o índice do frame a enviar de seguida. 93 | 94 | #### Receptor 95 | 96 | Rejeita qualquer frame fora da sequência, enviando somente ACK(i) para indicar que os frames i-1 foram enviados correctamente. i é sempre o número de sequência do próximo frame esperado. 97 | 98 | ##### Eficiência 99 | 100 | > S = W / (1+2a), se W < (1 + 2a), número de tramas que simultaneamente estão no cabo é inferior ao número de tramas da janela
101 | > S = 1, caso contrário
102 | 103 | ### Selective Repeat 104 | 105 | Usa a técnica da janela mas aceita tramas fora de ordem, ao contrário do Go Back N. Usada para casose em que `W` ou `a` são muito elevados. O receptor sinaliza a falta/erro no frame i, enviando SREJ(i) ao emissor e continuando a guardar no buffer as tramas seguintes. O emissor continua a enviar tramas e retransmite apenas o que é pedido pelo receptor. 106 | 107 | O tamanho da janela é agora W = M / 2 = 2^(k-1). Ou seja, o emissor pode enviar no máximo M/2 tramas sem confirmação por parte do receptor. 108 | Isto deve-se à justificação presente no livro recomendado, página 242 do capítulo 3: para o receptor não conter overlap da sua própria janela, então acaba por ter de enviar, no máximo, meia janela antes de receber um ACK. 109 | 110 | #### Eficiência 111 | 112 | > 113 | > 1 - pe, se W >= 1 + 2a
114 | > W * (1 - pe) / (1+2a), se W < 1 + 2a 115 | > 116 | 117 | ## Deteção de erros nas redes 118 | 119 | ### Ethernet 120 | 121 | Os frames são compostos por um **preamble** de 7 octetos, seguido de uma flag SFD, DA e SA, seguida do comprimento em bytes da informação enviada e posteriormente por uma redundância CRC. 122 | 123 | ### Point to Point Protocol 124 | 125 | A trama é delimitada por FLAG = 0x7E, existe byte stuffing com o ESC = 0x7D, algum tipo de deteção de erros (redundância e checksum), e um byte para endereço e outro para controlo. Semelhante ao implementado nas aulas de laboratório. 126 | 127 | ### Wireless LAN 128 | 129 | No início da trama tem um conjunto de bytes de sincronização. Normalmente usa um polinómio gerador de 16 bits e ARQ de Stop and Wait. 130 | 131 | ### High-level Data Link Control (HDLC) 132 | 133 | Usa flags para delimitar as tramas, usa bit stuffing, polinómio gerador de 16 bits e técnicas como o Selective Repeat e Go-Back N (suporta ambos). É a técnica mais usada pelos telemóveis para enviar dados. 134 | 135 | ## Fiabilidade 136 | 137 | Usando **técnicas de retransmissão** ou **técnicas de reconstrução**. Na physical layer pode haver FEC coding, que trata de dar redundância acrescida aos dados e assim, na parte do receptor, caso haja detecção de erros pode haver reconstrução dos bits iniciais.
138 | Em sistemas ARQ, os dados podem ser recuperados na data-link layer ou na transport layer. Há dois tipos: 139 | 140 | ### 1. Link-by-link ARQ 141 | 142 | Usada na `data link layer`. Os pacotes de dados caso se percam são pedidos ao emissor imediatamente pelo intermediário na rede e não pelo receptor final. Repara as perdas link por link, mas requer store de pacotes caso tenham de ser retransmitidos e um processamento maior entre intermediários. 143 | 144 | > PLR -> Packet Loss Ratio
145 | > C = bits/s
146 | > Capacidade = C * (1-PLR)
147 | 148 | ### 2. End-to-end ARQ 149 | 150 | Usada na `transport layer`. Só quando o receptor final perceber que um pacote se perdeu é que pede ao emissor para o retransmitir. É um processo com menor complexidade, mas não é aceitável quando a taxa de erros em tramas é elevada, como é o caso das ligações sem fio. 151 | 152 | > PLR -> Packet Loss Ratio
153 | > C = bits/s
154 | > k = número de links que formam a conexão
155 | > Capacidade = C * (1-PLR)^k
156 | 157 | #### TCP/IP 158 | 159 | No caso do protocolo TCP/IP, os pacotes perdidos são reparados: 160 | - Na data-link layer (wireless data links, através de ARQ quando o meio de propagação é propício a erros); 161 | - No receptor final (em transport ou application layers, quando o meio de propagação é fiável); -------------------------------------------------------------------------------- /Project1/src/link_layer.c: -------------------------------------------------------------------------------- 1 | // Link layer protocol implementation 2 | 3 | #include "link_layer.h" 4 | 5 | volatile int STOP = FALSE; 6 | int alarmTriggered = FALSE; 7 | int alarmCount = 0; 8 | int timeout = 0; 9 | int retransmitions = 0; 10 | unsigned char tramaTx = 0; 11 | unsigned char tramaRx = 1; 12 | 13 | int llopen(LinkLayer connectionParameters) { 14 | 15 | LinkLayerState state = START; 16 | int fd = connection(connectionParameters.serialPort); 17 | if (fd < 0) return -1; 18 | 19 | unsigned char byte; 20 | timeout = connectionParameters.timeout; 21 | retransmitions = connectionParameters.nRetransmissions; 22 | switch (connectionParameters.role) { 23 | 24 | case LlTx: { 25 | 26 | (void) signal(SIGALRM, alarmHandler); 27 | while (connectionParameters.nRetransmissions != 0 && state != STOP_R) { 28 | 29 | sendSupervisionFrame(fd, A_ER, C_SET); 30 | alarm(connectionParameters.timeout); 31 | alarmTriggered = FALSE; 32 | 33 | while (alarmTriggered == FALSE && state != STOP_R) { 34 | if (read(fd, &byte, 1) > 0) { 35 | switch (state) { 36 | case START: 37 | if (byte == FLAG) state = FLAG_RCV; 38 | break; 39 | case FLAG_RCV: 40 | if (byte == A_RE) state = A_RCV; 41 | else if (byte != FLAG) state = START; 42 | break; 43 | case A_RCV: 44 | if (byte == C_UA) state = C_RCV; 45 | else if (byte == FLAG) state = FLAG_RCV; 46 | else state = START; 47 | break; 48 | case C_RCV: 49 | if (byte == (A_RE ^ C_UA)) state = BCC1_OK; 50 | else if (byte == FLAG) state = FLAG_RCV; 51 | else state = START; 52 | break; 53 | case BCC1_OK: 54 | if (byte == FLAG) state = STOP_R; 55 | else state = START; 56 | break; 57 | default: 58 | break; 59 | } 60 | } 61 | } 62 | connectionParameters.nRetransmissions--; 63 | } 64 | if (state != STOP_R) return -1; 65 | break; 66 | } 67 | 68 | case LlRx: { 69 | 70 | while (state != STOP_R) { 71 | if (read(fd, &byte, 1) > 0) { 72 | switch (state) { 73 | case START: 74 | if (byte == FLAG) state = FLAG_RCV; 75 | break; 76 | case FLAG_RCV: 77 | if (byte == A_ER) state = A_RCV; 78 | else if (byte != FLAG) state = START; 79 | break; 80 | case A_RCV: 81 | if (byte == C_SET) state = C_RCV; 82 | else if (byte == FLAG) state = FLAG_RCV; 83 | else state = START; 84 | break; 85 | case C_RCV: 86 | if (byte == (A_ER ^ C_SET)) state = BCC1_OK; 87 | else if (byte == FLAG) state = FLAG_RCV; 88 | else state = START; 89 | break; 90 | case BCC1_OK: 91 | if (byte == FLAG) state = STOP_R; 92 | else state = START; 93 | break; 94 | default: 95 | break; 96 | } 97 | } 98 | } 99 | sendSupervisionFrame(fd, A_RE, C_UA); 100 | break; 101 | } 102 | default: 103 | return -1; 104 | break; 105 | } 106 | return fd; 107 | } 108 | 109 | int connection(const char *serialPort) { 110 | 111 | int fd = open(serialPort, O_RDWR | O_NOCTTY); 112 | if (fd < 0) { 113 | perror(serialPort); 114 | return -1; 115 | } 116 | 117 | struct termios oldtio; 118 | struct termios newtio; 119 | 120 | if (tcgetattr(fd, &oldtio) == -1) 121 | { 122 | perror("tcgetattr"); 123 | exit(-1); 124 | } 125 | 126 | memset(&newtio, 0, sizeof(newtio)); 127 | 128 | newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD; 129 | newtio.c_iflag = IGNPAR; 130 | newtio.c_oflag = 0; 131 | newtio.c_lflag = 0; 132 | newtio.c_cc[VTIME] = 0; 133 | newtio.c_cc[VMIN] = 0; 134 | 135 | tcflush(fd, TCIOFLUSH); 136 | 137 | if (tcsetattr(fd, TCSANOW, &newtio) == -1) { 138 | perror("tcsetattr"); 139 | return -1; 140 | } 141 | 142 | return fd; 143 | } 144 | 145 | void alarmHandler(int signal) { 146 | alarmTriggered = TRUE; 147 | alarmCount++; 148 | } 149 | 150 | int llwrite(int fd, const unsigned char *buf, int bufSize) { 151 | 152 | int frameSize = 6+bufSize; 153 | unsigned char *frame = (unsigned char *) malloc(frameSize); 154 | frame[0] = FLAG; 155 | frame[1] = A_ER; 156 | frame[2] = C_N(tramaTx); 157 | frame[3] = frame[1] ^frame[2]; 158 | memcpy(frame+4,buf, bufSize); 159 | unsigned char BCC2 = buf[0]; 160 | for (unsigned int i = 1 ; i < bufSize ; i++) BCC2 ^= buf[i]; 161 | 162 | int j = 4; 163 | for (unsigned int i = 0 ; i < bufSize ; i++) { 164 | if(buf[i] == FLAG || buf[i] == ESC) { 165 | frame = realloc(frame,++frameSize); 166 | frame[j++] = ESC; 167 | } 168 | frame[j++] = buf[i]; 169 | } 170 | frame[j++] = BCC2; 171 | frame[j++] = FLAG; 172 | 173 | int currentTransmition = 0; 174 | int rejected = 0, accepted = 0; 175 | 176 | while (currentTransmition < retransmitions) { 177 | alarmTriggered = FALSE; 178 | alarm(timeout); 179 | rejected = 0; 180 | accepted = 0; 181 | while (alarmTriggered == FALSE && !rejected && !accepted) { 182 | 183 | write(fd, frame, j); 184 | unsigned char result = readControlFrame(fd); 185 | 186 | if(!result){ 187 | continue; 188 | } 189 | else if(result == C_REJ(0) || result == C_REJ(1)) { 190 | rejected = 1; 191 | } 192 | else if(result == C_RR(0) || result == C_RR(1)) { 193 | accepted = 1; 194 | tramaTx = (tramaTx+1) % 2; 195 | } 196 | else continue; 197 | 198 | } 199 | if (accepted) break; 200 | currentTransmition++; 201 | } 202 | 203 | free(frame); 204 | if(accepted) return frameSize; 205 | else{ 206 | llclose(fd); 207 | return -1; 208 | } 209 | } 210 | 211 | int llread(int fd, unsigned char *packet) { 212 | 213 | unsigned char byte, cField; 214 | int i = 0; 215 | LinkLayerState state = START; 216 | 217 | while (state != STOP_R) { 218 | if (read(fd, &byte, 1) > 0) { 219 | switch (state) { 220 | case START: 221 | if (byte == FLAG) state = FLAG_RCV; 222 | break; 223 | case FLAG_RCV: 224 | if (byte == A_ER) state = A_RCV; 225 | else if (byte != FLAG) state = START; 226 | break; 227 | case A_RCV: 228 | if (byte == C_N(0) || byte == C_N(1)){ 229 | state = C_RCV; 230 | cField = byte; 231 | } 232 | else if (byte == FLAG) state = FLAG_RCV; 233 | else if (byte == C_DISC) { 234 | sendSupervisionFrame(fd, A_RE, C_DISC); 235 | return 0; 236 | } 237 | else state = START; 238 | break; 239 | case C_RCV: 240 | if (byte == (A_ER ^ cField)) state = READING_DATA; 241 | else if (byte == FLAG) state = FLAG_RCV; 242 | else state = START; 243 | break; 244 | case READING_DATA: 245 | if (byte == ESC) state = DATA_FOUND_ESC; 246 | else if (byte == FLAG){ 247 | unsigned char bcc2 = packet[i-1]; 248 | i--; 249 | packet[i] = '\0'; 250 | unsigned char acc = packet[0]; 251 | 252 | for (unsigned int j = 1; j < i; j++) 253 | acc ^= packet[j]; 254 | 255 | if (bcc2 == acc){ 256 | state = STOP_R; 257 | sendSupervisionFrame(fd, A_RE, C_RR(tramaRx)); 258 | tramaRx = (tramaRx + 1)%2; 259 | return i; 260 | } 261 | else{ 262 | printf("Error: retransmition\n"); 263 | sendSupervisionFrame(fd, A_RE, C_REJ(tramaRx)); 264 | return -1; 265 | }; 266 | 267 | } 268 | else{ 269 | packet[i++] = byte; 270 | } 271 | break; 272 | case DATA_FOUND_ESC: 273 | state = READING_DATA; 274 | if (byte == ESC || byte == FLAG) packet[i++] = byte; 275 | else{ 276 | packet[i++] = ESC; 277 | packet[i++] = byte; 278 | } 279 | break; 280 | default: 281 | break; 282 | } 283 | } 284 | } 285 | return -1; 286 | } 287 | 288 | int llclose(int fd){ 289 | 290 | LinkLayerState state = START; 291 | unsigned char byte; 292 | (void) signal(SIGALRM, alarmHandler); 293 | 294 | while (retransmitions != 0 && state != STOP_R) { 295 | 296 | sendSupervisionFrame(fd, A_ER, C_DISC); 297 | alarm(timeout); 298 | alarmTriggered = FALSE; 299 | 300 | while (alarmTriggered == FALSE && state != STOP_R) { 301 | if (read(fd, &byte, 1) > 0) { 302 | switch (state) { 303 | case START: 304 | if (byte == FLAG) state = FLAG_RCV; 305 | break; 306 | case FLAG_RCV: 307 | if (byte == A_RE) state = A_RCV; 308 | else if (byte != FLAG) state = START; 309 | break; 310 | case A_RCV: 311 | if (byte == C_DISC) state = C_RCV; 312 | else if (byte == FLAG) state = FLAG_RCV; 313 | else state = START; 314 | break; 315 | case C_RCV: 316 | if (byte == (A_RE ^ C_DISC)) state = BCC1_OK; 317 | else if (byte == FLAG) state = FLAG_RCV; 318 | else state = START; 319 | break; 320 | case BCC1_OK: 321 | if (byte == FLAG) state = STOP_R; 322 | else state = START; 323 | break; 324 | default: 325 | break; 326 | } 327 | } 328 | } 329 | retransmitions--; 330 | } 331 | 332 | if (state != STOP_R) return -1; 333 | sendSupervisionFrame(fd, A_ER, C_UA); 334 | return close(fd); 335 | } 336 | 337 | unsigned char readControlFrame(int fd){ 338 | 339 | unsigned char byte, cField = 0; 340 | LinkLayerState state = START; 341 | 342 | while (state != STOP_R && alarmTriggered == FALSE) { 343 | if (read(fd, &byte, 1) > 0 || 1) { 344 | switch (state) { 345 | case START: 346 | if (byte == FLAG) state = FLAG_RCV; 347 | break; 348 | case FLAG_RCV: 349 | if (byte == A_RE) state = A_RCV; 350 | else if (byte != FLAG) state = START; 351 | break; 352 | case A_RCV: 353 | if (byte == C_RR(0) || byte == C_RR(1) || byte == C_REJ(0) || byte == C_REJ(1) || byte == C_DISC){ 354 | state = C_RCV; 355 | cField = byte; 356 | } 357 | else if (byte == FLAG) state = FLAG_RCV; 358 | else state = START; 359 | break; 360 | case C_RCV: 361 | if (byte == (A_RE ^ cField)) state = BCC1_OK; 362 | else if (byte == FLAG) state = FLAG_RCV; 363 | else state = START; 364 | break; 365 | case BCC1_OK: 366 | if (byte == FLAG){ 367 | state = STOP_R; 368 | } 369 | else state = START; 370 | break; 371 | default: 372 | break; 373 | } 374 | } 375 | } 376 | return cField; 377 | } 378 | 379 | int sendSupervisionFrame(int fd, unsigned char A, unsigned char C){ 380 | unsigned char FRAME[5] = {FLAG, A, C, A ^ C, FLAG}; 381 | return write(fd, FRAME, 5); 382 | } -------------------------------------------------------------------------------- /Notes/Exam.md: -------------------------------------------------------------------------------- 1 | # Preparação para o Exame 2 | 3 | ## Tópicos 4 | 5 | 0. Introduction 6 | 1. Physical Layer 7 | - 1.1 Shannon's Law 8 | - 1.2 Meios de Propagação 9 | 2. DataLink Layer 10 | - 2.1 Error detection 11 | - 2.2 Automatic Repeat Request 12 | 3. Network Layer 13 | - 3.1 DHCP 14 | - 3.2 NAT 15 | - 3.3 ICMP 16 | - 3.4 IPv6 17 | - 3.5 DN 18 | 4. Transport Layer 19 | - 4.1 UDP 20 | - 4.2 TCP 21 | - 4.3 Routing 22 | 5. Application Layer 23 | 24 | ## 0 - Introduction 25 | 26 | As redes podem ser classificadas de acordo com a sua extensão (PAN, LAN, MAN, WAN, Internet, PLMWI) e são baseadas numa stack de camadas onde são passados os pacotes de informação (PDNTA): 27 | 28 | 1. Physical Layer - Passagem dos bits dos pacotes de dados por canais físicos; 29 | 2. DataLink Layer - Passagem de pacotes entre elementos das redes; 30 | 3. Network Layer - Roteamento dos pacotes de um lado para outro; 31 | 4. Transport Layer - Com os protocolos TCP ou UDP; 32 | 5. Application Layer - Suporta a aplicação, como o FTP, SMTP e HTTP; 33 | 34 | A passagem de pacotes pode ser por dois métodos: 35 | 36 | - `Circuit Switching`, só quando a ligação é estabelecida é que os pacotes são enviados; 37 | - `Packet Switching`, passagem de pacotes pelos intermediários e segundo a ordem na fila; 38 | 39 | ## 1 - Physical Layer 40 | 41 | No meio físico, de acordo com Nyquist, um sinal de frequência X Hz pode ser reconstruído se se capturar 2X símbolos / segundo. A capacidade de um canal com M níveis é definido como C = 2B*Log(M) símbolos ou bits / segundo. A transmissão pode ser: 42 | 43 | - *Baseband* - de 0 até um valor de frequência máximo BH. É característico dos fios; 44 | - *Passband or BandPass* - em torno de uma frequência FC. É característico de wireless e optical channels; 45 | 46 | De qualquer das formas, os bits da transmissão podem ser descodificados de algumas formas: 47 | 48 | - NRZ-L (Non Return to Zero - Level), um nível superior representa 0 e o inferior representa 1; 49 | - NRZ-I (Non Return to Zero - Inverted), a mudança de nível representa 1; 50 | - Manchester, uma descida é 1, a subida é 0, usada na Ethernet; 51 | 52 | Para descodificar os símbolos é necessário ter suficientes transições, pelo que é normal misturar ciclos de relógio com cada símbolo transmitido. Para sinais contínuos, podemos usar modulações binárias, de mudança de amplitude, frequência e fase. 53 | 54 | ### 1.1 - Shannon's Law 55 | 56 | Na realidade a capacidade teórica de um canal é dada em função do ruído captado do receptor, logo M = 1 + SNR (Signal to Noise Ratio). Assim é proporcional à largura de banda e como um sinal muito superior ao nível de ruído é proporcional ao logaritmo de SNR. 57 | 58 | ### 1.2 - Meios de Propagação 59 | 60 | - Coaxial Cable, grande imunidade a ruído e com baixa atenuação, usado para grandes larguras de banda; 61 | - Unshielded twisted pair; 62 | - Fiber optic, para grandes larguras de banda e com muito pouca atenuação, embora tenha alguma perda devido à reflexão total; 63 | 64 | Para transmissões wireless em antenas a razão entre a potência emitida e recebida é igual a (4 * pi * frequência * distância / c) ^ 2 65 | 66 | ## 2 - DataLink Layer 67 | 68 | Camada que regula a transmissão, retransmissão, integridade e gestão de erros provenientes da transmissão da informação de forma física pela Physical Layer. Para o envio da informação (cadeias de bits) é necessário recorrer a *framming*, através: 69 | - da contagem de bits, cada frame é constuído pela quantidade de dados seguida desses mesmos dados; 70 | - da existência de um bit de término com *stuffing*; 71 | - da existência de flags de início e término, também com *stuffing*; 72 | 73 | ### 2.1 - Error detection 74 | 75 | Os erros podem ser simples (independentes de erros anteriores) ou em *bursts*, conjuntos dependentes. Para determinar probabilidades usa-se o FER (*Frame Error Ratio*) e o BER (*Bit Error Ratio*). Para deteção de erros usa-se um bit de paridade (onde o bit é 1 quando existe um número ímpar/par de 1s na trama), uma paridade bidimensional (com d = 4). 76 | 77 | #### CRC - Cyclic redundancy check 78 | 79 | Dado um polinómio M(x) derivado dos bits a transmitir, e r bits de redundância, faz-se R(x) = M(x) * x^r / (x^r + 1). Envia-se M(x) * x^r + R(x). Do lado do receptor é só fazer a divisão inteira de T(x) por G(x) e o resultado tem de ser zero. Detecta 1,2 ou 3 bits com erro. 80 | 81 | ### 2.2 - Automatic Repeat Request (ARQ) 82 | 83 | Para pacotes perdidos ou com erros, o receptor retransmite a informação. Para isso há três métodos: 84 | 85 | #### Stop and Wait 86 | 87 | O transmissor envia e fica à espera por timeout da resposta (ACK). Se a resposta não for afirmativa ou não vier em tempo útil, reenvia a informação. Os frames são numerados, assim como as respostas e são descartados duplicados para não haver sobreposição. A eficiência é dada por 1 / (1 + 2 * x), com x sendo a relação entre o tempo de propagação (depende da distância percorrida) e o tempo de transferência da trama (depende do tamanho da trama). A eficiência é muito baixa quando o valor de x (ou a distância percorrida) é grande, ou seja, quando a trama tem tamanho muito inferior à distância percorrida. 88 | 89 | #### Go-Back N / Sliding Window Protocol 90 | 91 | Uma janela de ordem K permite o envio de até K frames antes de esperar pelas respostas, para aumento da eficiência do Stop and Wait. O receptor rejeita frames fora da sequência e a resposta ACK(i) permite identificar que todos os pacotes de ordem até i-1 foram enviados correctamente. O número máximo de K é 2^M-1, com M = número de bits necessários para codificar o índice das respostas e correspondentes frames. Neste caso a eficiência é W / (1 + 2 * x). 92 | 93 | #### Selective Repeat 94 | 95 | Parecido com o anterior mas aceita tramas fora de ordem. Usado para casos em que x ou W são muito elevados. O receptor sinaliza a falta/erro da trama I com REJ(I) e o transmissor reenvia apenas o que é pedido pelo receptor. O tamanho da janela é agora W = M / 2 = 2^(k-1), com k igual ao número de bits suficientes para codificar o índex da trama. O transmissor envia no máximo meia janela antes de receber um ACK para não ocorrer sobreposição das suas tramas na janela. A nível de eficiência é dado por expressões semelhantes às anteriores. 96 | 97 | #### Link-to-Link ARQ 98 | 99 | Os erros ou perdas são detectados entre cada par de links e não nas pontas da transmissão. Necessita que a rede lembre o estado, o que provoca um maior processamento interno e memória usada. 100 | 101 | #### End-to-End ARQ 102 | 103 | Só nas pontas é que são detectados os erros ou perdas. A complexidade intermédia é baixa mas não é usada para sistemas com grande distância ou com grande percentagem de erros. 104 | 105 | ### 2.3 - Delay Models 106 | 107 | #### Multiplexing 108 | 109 | Usar o mesmo canal de capacidade C para enviar diferentes tipos de pacotes. Pode ser numa única fila, em M filas fixas pelo tempo (*Time Division Multiplexing*) e em M filas fixas pela frequência (*Frequency Division Multiplexing*). Nestes dois últimos casos o delay provocado é diretamente proporcional a M e a capacidade de cada canal inversamente proporcional a M. 110 | 111 | #### Poisson Processes 112 | 113 | Seja Lambda o número de chegadas de pacotes por segundo e T o número de segundos: 114 | - Probabilidade de chegar X pacotes é ((Lambda * T)^x * e^(-Labda * T)) / (X!); 115 | - Probabilidade do tempo de chegada ser menor que A é (1 - e^(Lambda * T)); 116 | - O tempo médio é dado por Lambda * e^(-Lambda * T) 117 | 118 | - Lambda -> O número de pacotes que chegam por unidade de tempo 119 | - Miu -> O número de pacotes servidor por unidade de tempo 120 | - Ró -> Relação entre Lambda e Miu, dá a intensidade de tráfego e a ocupação do servidor 121 | 122 | #### Kendalls Notation A/S/s/K 123 | 124 | A -> Processo de chegada de pacotes 125 | S -> Processo de serviço dos pacotes 126 | s -> Número de servidores 127 | K -> Capacidade do sistema, normalmente infinito para sistemas estáveis 128 | 129 | A Little's Law indica que N = Lambda * T, com N a representar o número de clientes do sistema (os que vão chegando e os que estão a ser tratados no momento). O número de clientes no sistema não dependem de Miu, a taxa de serviço. 130 | 131 | #### Cadeia de Markov 132 | 133 | Usada para sistemas M/M/1/Inf estáveis. A probabilidade de chegar um novo pacote à fila num tempo Sigma é Lambda * Sigma e a probabilidade de um pacote ser atendido é Miu * Sigma. A probabilidade de estar num estado N é Ró ^ N * (1 - Ró). 134 | 135 | - Nos modelos de Poisson de chegada de pacotes, uma taxa de serviço alta não é sinónimo de um número pequeno de pacotes à espera (porque os pacotes tendem a chegar todos juntos); 136 | 137 | - Nos modelos discretos de chegada de pacotes (D/D/1), não vai haver espera, considerando um sistema estável (a taxa de chegada <= taxa de processamento); 138 | 139 | #### Redes de filas de espera 140 | 141 | Não se pode admitir uma cadeia linear com base na cadência de Poisson. No entanto dá para aproximar, tornando-se uma cadeia subdividida (Kleinrock Independence Approximation) através do modelo M/M/1 ou em redes de Jackson. 142 | 143 | ### 2.4 - MAC Sublayer 144 | 145 | A DataLink Layer subdivide-se nas camadas LLC (Logical Link Layer), responsável por fluxo de dados e detecção de erros, e MAC (Medium Access Control), responsável por controlo de acesso, recepção e retransmissão da informação. Numa situação normal, vários são os computadores que usam o mesmo canal para comunicar. Para M computadores, cada computador tem direito a C/M da capacidade total do canal se forem todos tentar comunicar entre si, ou C se cada um esperar por sua vez. 146 | 147 | #### Channel Partitioning Protocols 148 | 149 | Time Division Multiple Access ou Frequency Division Multiple Access. Custará na eficiência de cada chamada pois agora cada emissor tem que partilhar o meio (ou por slots de tempo ou por frequência). 150 | 151 | #### Random Access Protocols 152 | 153 | Acontecem quando numa rede todos os emissores têm a mesma prioridade: 154 | 155 | - ALOHA: envia o pacote para a rede esperando K tempo para a resposta, com K random. Usado para sistemas de baixa frequência de utilização; 156 | - CSMA (Carrier Sense Multiple Access): se ninguém estiver a transmitir, lança o pacote na rede. Pode ser persistente, transmite quando o canal estiver desocupado tentando sempre ver de está livre, ou não persistente, quando ainda espera um tempo random R antes de cada tentativa de ver se está livre e só depois é que transmite, ou P-Persistente, quando transmite de um modo ou outro com probabilidade P. De qualquer modo espera sempre por ACK; 157 | - CSMA/CD: Com deteção de colisões, e nesse caso aborta. Transmite novamente mas após esperar um tempo exponencial (Binary Exponential Backoff). Tramas curtas podem impedir a deteção de colisões sob o ponto de vista do emissor. O tempo de transmissão da trama deve ser maior do que duas vezes o tempo de ida e volta (tempo de propagação). Não dá para ser usada em sistemas sem fios devido às distorções causadas pelo meio, iria "detectar" colisões não tendo nenhuma ou não conseguiria ouvir a frequência do outro emissor pois as distâncias são elevadas. 158 | - CSMA/CA: Evita erros, esperando ainda um tempo exponencial depois que descobrir que o canal está livre. É necessário voltar a haver ACK e é característica das redes sem fios. 159 | 160 | #### Taking Turns Protocols 161 | 162 | - Polling: quando existe um computador Master na rede que dá autorização para as outras transferirem pacotes. Se os tempos forem bem implementados não há colisões mas perde-se algum tempo em espera ou na transmissão dos pedidos; 163 | - Token Passing: só há transmissão de pacotes por parte dos edges que têm o token. Há latência pois tem de haver passagem do token; 164 | 165 | ### 2.5 - Evolução da internet na Link Layer 166 | 167 | - Bus - com cabo coaxial, os computadores ligavam-se através de um cabo onde podia haver colisões e múltiplos transmissores e receptores. 168 | - Active Hub - existem repetidores que enviam os bits recebidos para todos as outras portas. Existe deteção de colisão, mas só numa única porta de cada vez. 169 | - Bridge - Separa os domínios de colisão e vários frames podem ser transmitidos simultaneamente. 170 | - Full Duplex Ethernet - o CSMA/CD não é usado praticamente, pois não existem colisões. Os cabos UTP são usados (Unshielded Twisted Pair), que são mais baratos e fáceis de instalar, embora não suportem bem múltiplas transmissões ou receptores; 171 | - Ethernet de hoje em dia - UTP para distâncias curtas, fibras óticas para longas, suporta redundância para minimizar erros; 172 | 173 | ## 3 - Network Layer 174 | 175 | Transporta os pacotes de dados da origem ao destino e calcula caminhos através de grafos. O encaminhamento de pacotes pode ser por **Virtual Circuits** (todos os pacotes são enviados sequencialmente se houver um caminho estável entre o primeiro e último routers) ou por **Datagrams Networks**, quando os pacotes são enviados sem um caminho definido, o que é mais difícil de gerir e podem vir fora de ordem. 176 | 177 | ### 3.1 - DHCP - Dynamic Host Configuration Protocol 178 | 179 | Para obtenção de IP por parte de um HOST a partir do server da rede. Segue respostas DORA (Discovery, Offer, Request, Ack), em que as três últimas já vêm com o IP único para aquela subrede. 180 | 181 | ### 3.2 - NAT - Network Address Translation 182 | 183 | Network Address Translation. Por motivos de IPv4 usado internamente não há IPs suficientes, pelo que a Internet contacta com um único router de casa, que fica encarregue de traduzir os endereços e redirecionar os pacotes. Em casos excepcionais, existe a NAT transversal, que permite contacto directo com um host privado a partir de uma entrada específica na tabela. 184 | 185 | ### 3.3 - ICMP - Internet Control Message Protocol 186 | 187 | Serve para descobrir rotas e fazer redirects para caminhos mais curtos / com menos custo 188 | 189 | ### 3.4 - IPv6 Addresses 190 | 191 | - Unicast: um sender e um receiver; 192 | - Multicast: um sender e vários receivers; 193 | - Anycast: proporciona iguais IDs para vários receivers; 194 | - Link-local: para redes privadas; 195 | 196 | ### 3.5 - ND - Neighbor Discovery Protocol 197 | 198 | Usa mensagens ICMPv6 com Link Local Addresses para descobrir novos nós da mesma LAN, descobrir os routers da rede e manter atualizados as características dos nós vizinhos. As mensagens trocadas podem ser as seguintes: 199 | 200 | - Neighbor solicitation/advertisement, para obter o endereço MAC do vizinho ou saber se ele está presente; 201 | - Router solicitation/advertisement, usado pelos routers para enviar informação sobre o prefixo da rede; 202 | - Redirect, para informar um host sobre a melhor rota a tomar; 203 | 204 | ## 4 - Transport Layer 205 | 206 | ### 4.1 - User Datagram Protocol (UDP) 207 | 208 | Não tem um mecanismo de controlo de erros mas como é mais simples permite contacto direto com o IP de destino sem muito overhead, enviando diretamente os dados. Só tem um checksum que é opcional. 209 | 210 | ### 4.2 - Transmission Control Protocol (TCP) 211 | 212 | Orientado às comunicações, com base em ACK e NACK, e incorpora o controlo de fluxo e controlo de congestionamento. Os números de sequência correspondem ao primeiro byte transferido naquela trama, para depois poder ser ordenado e descarta duplicados. Por um lado há **controlo de fluxo** pois há o parâmetro Advertise Window que indica a quantidade de espaço que ainda tem disponível. O tempo de retransmissão é feito iterativamente usando uma *Adaptative Retransmission*, em que há retransmissão apenas dos blocos selecionados. Por outro lado há **controlo de congestionamento**, com *additive increase* e *multiplicative decrease* da CongestionWindow: 213 | - Sempre que leva time-out, baixa, vai até metade em slow start e depois additive increase; 214 | - Sempre que levar 3 ACKs repetidos, baixa, e depois additive increase; 215 | 216 | ### 4.3 - Routing 217 | 218 | A escolha de um bom caminho (boa largura de banda, curta distância, baixa latência) é importante para garantir a eficiência da rede e limitar a quantidade de pacotes perdidos no processo. A Spanning Tree pode ser realizada por: 219 | - Algoritmo de Dijkstra, onde as mensagens trocadas são mais localizadas (partilha informação do nó N e nós adjacentes a N apenas), o que provoca um delay grande se a rede for considerável; 220 | - Algoritmo de Bellman-Ford, onde trocam-se as Fowarding Tables em vez de mensagens soltas, as mensagens são mais longas mas as modificações perpetuam-se na rede mais rapidamente; 221 | 222 | #### RIP - Routing Information Protocol 223 | 224 | Protocolo que gere a distância entre os routers. Os routers enviam a sua distância aos outros de 30 em 30 segundos ou quando um update causa uma modificação na rede em si. Está limitado a pequenas redes. 225 | 226 | ### STP - Spanning Tree Protocol 227 | 228 | Protocolo existente nas bridges presentes nos switches da rede. Aqui os routers não constroem as suas próprias Spanning Tree, existindo apenas uma árvore no sistema que é construída por mensagens trocadas entre switches. As mensagens são do tipo (root da árvore atual, distância de ligação, origem). Inicialmente todos os switches assumem que eles próprios são a raiz da árvore. À medida que as mensagens são trocadas, os switches admitem sempre que a raiz da árvore é agora o switch que contém o menor número identificador. Os switches bloqueiam algumas portas para que não existam ciclos. 229 | 230 | ## 5 - Application Layer 231 | 232 | Esta camada define os tipos de mensagens trocadas, a sintaxe e semântica delas e as regras de envio e resposta por parte dos processos. Por exemplo o protocolo HTTP(S), que pode ser não-persistente (um recurso por conexão TCP, 2 * RTT + FileTransferTime) ou persistente (vários recursos numa mesma conexão TCP). Esta última pode ser com *pipelining*, para vários requests sem esperar pela resposta (um RTT para tudo), ou sem *pipelining*, quando novos requests são feitos só depois de receber a resposta ao anterior (cada request tem direito ao seu RTT). O IMAP permite manipular mensagens existentes no servidor e guarda o estado entre sessões. O POP3 serve para autorização de conexão entre o servidor e para download de mensagens entre serviços, mas não guarda o estado entre sessões. --------------------------------------------------------------------------------