Sprzęt i oprogramowanie sieciowe

Sprzęt i oprogramowanie sieciowe
Zbigniew Kulesza

EIA232 Wprowadzony w 1960r. Od 1997 Electronic Industry Association EIA-232 (!!!) Ostatnia edycja 1997 – EIA232F Opiera się na modelu komunikacyjnym: DTE device (Data Terminal Equipment, zwykle komputer lub terminal) DCE device (Data Circuit-terminating Equipment, zwykle modem) Data Communications Equipment (też spotykana nazwa) RS232C indicates a DB25 (DB9), RS232D indicates an RJ45

Typy kanałów komunikacji

Transmisja asynchroniczna I

Transmisja asynchroniczna II

Model DTE - DCE

Definicja sygnałów

Definicja sygnałów – ground/shield
Pin 7, Pin 1, and the shell are included in this category. Cables provide separate paths for each, but internal wiring often connects pin 1 and the cable shell/shield to signal ground on pin 7. Pin 7 - Ground All signals are referenced to a common ground, as defined by the voltage on pin 7. This conductor may or may not be connected to protective ground inside the DCE device. The existence of a defined ground potential within the cable makes the EIA232 standard different from a balanced differential voltage standard, such as EIA530, which provides far greater noise immunity.

Definicja sygnałów – pierwszy kanał komunikacyjny I
Pin 2 - Transmitted Data (TxD) This signal is active when data is transmitted from the DTE device to the DCE device. When no data is transmitted, the signal is held in the mark condition (logic '1', negative voltage). NOTE: Pin 2 on the DCE device is commonly labeled "Received Data", although by the EIA232 standard it should still be called Transmitted Data because the data is thought to be destined for a remote DTE device.

Definicja sygnałów – pierwszy kanał komunikacyjny II
Pin 3 - Received Data (RxD) This signal is active when the DTE device receives data from the DCE device. When no data is transmitted, the signal is held in the mark condition (logic '1', negative voltage). NOTE: Pin 3 on the DCE device is commonly labeled "Transmitted Data", although by the EIA232 standard it should still be called Received Data because the data is thought to arrive from a remote DTE device.

Definicja sygnałów – pierwszy kanał komunikacyjny III
Pin 4 - Request to Send (RTS) This signal is asserted (logic '0', positive voltage) to prepare the DCE device for accepting transmitted data from the DTE device. Such preparation might include enabling the receive circuits, or setting up the channel direction in half-duplex applications. When the DCE is ready, it acknowledges by asserting Clear to Send. NOTE: Pin 4 on the DCE device is commonly labeled "Clear to Send", although by the EIA232 standard it should still be called Request to Send because the request is thought to be destined for a remote DTE device.

Definicja sygnałów – pierwszy kanał komunikacyjny IV
Pin 5 - Clear to Send (CTS) This signal is asserted (logic '0', positive voltage) by the DCE device to inform the DTE device that transmission may begin. RTS and CTS are commonly used as handshaking signals to moderate the flow of data into the DCE device. NOTE: Pin 5 on the DCE device is commonly labeled "Request to Send", although by the EIA232 standard it should still be called Clear to Send because the signal is thought to originate from a remote DTE device.

Definicja sygnałów – drugi kanał komunikacyjny IV
Pin 14 - Secondary Transmitted Data (STxD) Pin 16 - Secondary Received Data (SRxD) Pin 19 - Secondary Request to Send (SRTS) Pin 13 - Secondary Clear to Send (SCTS) These signals are equivalent to the corresponding signals in the primary communications channel. The baud rate, however, is typically much slower in the secondary channel for increased reliability.

Definicja sygnałów – modem status I
Pin 6 - DCE Ready (DSR) When originating from a modem, this signal is asserted (logic '0', positive voltage) when the following three conditions are all satisfied: 1 - The modem is connected to an active telephone line that is "off-hook“; 2 - The modem is in data mode, not voice or dialing mode; and 3 - The modem has completed dialing or call setup functions and is generating an answer tone.

Definicja sygnałów – modem status II
If the line goes "off-hook", a fault condition is detected, or a voice connection is established, the DCE Ready signal is deasserted (logic '1', negative voltage). IMPORTANT: If DCE Ready originates from a device other than a modem, it may be asserted to indicate that the device is turned on and ready to function, or it may not be used at all. If unused, DCE Ready should be permanently asserted (logic '0', positive voltage) within the DCE device or by use of a self-connect jumper in the cable. Alternatively, the DTE device may be programmed to ignore this signal.

Definicja sygnałów – modem status III
Pin 20 - DTE Ready (DTR) This signal is asserted (logic '0', positive voltage) by the DTE device when it wishes to open a communications channel. If the DCE device is a modem, the assertion of DTE Ready prepares the modem to be connected to the telephone circuit, and, once connected, maintains the connection. When DTE Ready is deasserted (logic '1', negative voltage), the modem is switched to "on-hook" to terminate the connection.

Definicja sygnałów – modem status IV
IMPORTANT: If the DCE device is not a modem, it may require DTE Ready to be asserted before the device can be used, or it may ignore DTE Ready altogether. If the DCE device (for example, a printer) is not responding, confirm that DTE Ready is asserted before you search for other explanations.

Definicja sygnałów – modem status V
Pin 8 - Received Line Signal Detector (CD) (also called Carrier Detect) This signal is relevant when the DCE device is a modem. It is asserted (logic '0', positive voltage) by the modem when the telephone line is "off-hook", a connection has been established, and an answer tone is being received from the remote modem. The signal is deasserted when no answer tone is being received, or when the answer tone is of inadequate quality to meet the local modem's requirements (perhaps due to a noisy channel).

Definicja sygnałów – modem status VI
Pin 12 - Secondary Received Line Signal Detector (SCD) This signal is equivalent to the Received Line Signal Detector (pin 8), but refers to the secondary channel.

Definicja sygnałów – modem status VII
Pin 22 - Ring Indicator (RI) This signal is relevant when the DCE device is a modem, and is asserted (logic '0', positive voltage) when a ringing signal is being received from the telephone line. The assertion time of this signal will approximately equal the duration of the ring signal, and it will be deasserted between rings or when no ringing is present.

Definicja sygnałów – modem status VII
Pin 23 - Data Signal Rate Selector This signal may originate either in the DTE or DCE devices (but not both), and is used to select one of two prearranged baud rates. The asserted condition (logic '0', positive voltage) selects the higher baud rate.

Definicja sygnałów – s. czasowe nadajnika i odbiornika I
Pin 15 - Transmitter Signal Element Timing (TC) (also called Transmitter Clock) This signal is relevant only when the DCE device is a modem and is operating with a synchronous protocol. The modem generates this clock signal to control exactly the rate at which data is sent on Transmitted Data (pin 2) from the DTE device to the DCE device. The logic '1' to logic '0' (negative voltage to positive voltage) transition on this line causes a corresponding transition to the next data element on the Transmitted Data line. The modem generates this signal continuously, except when it is performing internal diagnostic functions.

Definicja sygnałów – s. czasowe nadajnika i odbiornika II
Pin 17 - Receiver Signal Element Timing (RC) (also called Receiver Clock) This signal is similar to TC described above, except that it provides timing information for the DTE receiver.

Definicja sygnałów – s. czasowe nadajnika i odbiornika III
Pin 24 - Transmitter Signal Element Timing (ETC) (also called External Transmitter Clock) Timing signals are provided by the DTE device for use by a modem. This signal is used only when TC and RC (pins 15 and 17) are not in use. The logic '1' to logic '0' transition (negative voltage to positive voltage) indicates the time-center of the data element. Timing signals will be provided whenever the DTE is turned on, regardless of other signal conditions.

Definicja sygnałów – testy kanału I
Pin 18 - Local Loopback (LL) This signal is generated by the DTE device and is used to place the modem into a test state. When Local Loopback is asserted (logic '0', positive voltage), the modem redirects its modulated output signal, which is normally fed into the telephone line, back into its receive circuitry. This enables data generated by the DTE to be echoed back through the local modem to check the condition of the modem circuitry. The modem asserts its Test Mode signal on Pin 25 to acknowledge that it has been placed in local loopback condition.

Definicja sygnałów – testy kanału II
Pin 21 - Remote Loopback (RL) This signal is generated by the DTE device and is used to place the remote modem into a test state. When Remote Loopback is asserted (logic '0', positive voltage), the remote modem redirects its received data back to its transmitted data input, thereby remodulating the received data and returning it to its source. When the DTE initiates such a test, transmitted data is passed through the local modem, the telephone line, the remote modem, and back, to exercise the channel and confirm its integrity. The remote modem signals the local modem to assert Test Mode on pin 25 when the remote loopback test is underway.

Definicja sygnałów – testy kanału III
Pin 25 - Test Mode (TM) This signal is relevant only when the DCE device is a modem. When asserted (logic '0', positive voltage), it indicates that the modem is in a Local Loopback or Remote Loopback condition. Other internal self-test conditions may also cause Test Mode to be asserted, and depend on the modem and the network to which it is attached.

Standard elektryczny The EIA232 standard uses negative, bipolar logic in which a negative voltage signal represents logic '1', and positive voltage represents logic '0'.

Wspólna masa sygnałowa
The EIA232 standard includes a common ground reference on Pin 7, and is frequently joined to Pin 1 and a circular shield that surrounds all 25 cable conductors. Data, timing, and control signal voltages are measured with respect to this common ground. EIA232 cannot be used in applications where the equipment on opposite ends of the connection must be electrically isolated. NOTE: optical isolators may be used to achieve ground isolation, however, this option is not mentioned or included in the EIA232 specification.

Charakterystyka sygnału I

Charakterystyka sygnału II
This is the equivalent circuit for an EIA232 signal line and applies to signals originating at either the DTE or DCE side of the connection. "Co" is not specified in the standard, but is assumed to be small and to consist of parasitic elements only. "Ro" and "Vo" are chosen so that the short-circuit current does not exceed 500ma. The cable length is not specified in the standard; acceptable operation is experienced with cables that are less than 25 feet in length.

Przypisanie sygnałów

Odporność na zwarcia The generator is designed to withstand an open-circuit (unconnected) condition, or short-circuit condition between its signal conductor and any other signal conductor, including ground, without sustaining damage to itself or causing damage to any associated circuitry. The receiver is also designed to accept any signal voltage within the range of ±25 volts without sustaining damage. CAUTION: Inductive loads or magnetically induced voltages resulting from long cables may cause the received voltage to exceed the ±25-volt range momentarily during turn-on transients or other abnormal conditions, possibly causing damage to the generator, receiver, or both. Keep the cable length as short as possible, and avoid running the cable near high-current switching loads like electric motors or relays.

Odporność na uszkodzenia
Four signals are intended to be fail-safe in that during power-off or cable-disconnected conditions, they default to logic '1' (negative voltage). They are: Request to Send - Default condition is deasserted. Sec. Request to Send - Default condition is deasserted. DTE Ready - Default condition is DTE not ready. DCE Ready - Default condition is DCE not ready.

Szybkość transmisji The EIA232 standard is applicable to data rates of up to 20,000 bits per second (the usual upper limit is 19,200 baud). Fixed baud rates are not set by the EIA232 standard. However, the commonly used values are 300, 1200, 2400, 9600, and 19,200 baud. Other accepted values that are not often used are 110 (mechanical teletype machines), 600, and 4800 baud.

Stany przejściowe I 1 - Signals that enter the transition region during a change of state must move through the transition region to the opposite signal state without reversing direction or reentering. 2 - For control signals, the transit time through the transition region should be less than 1ms.

Stany przejściowe II 3 - For Data and Timing signals, the transit time through the transition region should be a - less than 1ms for bit periods greater than 25ms, b - 4% of the bit period for bit periods between 25ms and 125µs, c - less than 5µs for bit periods less than 125µs. The rise and fall times of data and timing signals ideally should be equal, but in any case vary by no more than a factor of three. 4 - The slope of the rising and falling edges of a transition should not exceed 30v/µS. Rates higher than this may induce crosstalk in adjacent conductors of a cable.

Stany przejściowe III

Podstawowe połączenie DTE-DCE

Połączenie 9-pin DTE - DCE

Połączenie 9-pin DTE - loopback

Połączenie 9-pin DTE – DTE (DCE - DCE) – Null Modem

Połączenie 25-pin DTE – 9-pin DCE

Połączenie 25-pin DTE – 9-pin DCE (pin 1 - ekranowanie)

Połączenie 25-pin DTE - loopback

Połączenie 25-pin DTE – 25-pin DTE (DCE-DCE) - Null Modem – no handshake

Połączenie 25-pin DTE – 25-pin DTE (DCE-DCE) – Null Modem std
Połączenie 25-pin DTE – 25-pin DTE (DCE-DCE) – Null Modem std. handshake

Połączenie 25-pin DTE – 25-pin DTE (DCE-DCE) – Null Modem unusual handshake

Połączenie 25-pin DTE – 25-pin DTE (DCE-DCE) – Null Modem synchronous communications

Połączenie 25-pin DTE – 25-pin DTE (DCE-DCE) – Null Modem niekonwencjonalny

Kontroler procesora S3C44B0X

Rejestr kontrolny I

Rejestr kontrolny II

Rejestr kontrolny FIFO

Rejestr kontrolny modemu

Rejestr statusu

Rejestr błędów

Rejestr statusu FIFO

Rejestr statusu modemu

Rejestr bufora transmisji

Rejestr bufora odbioru

Rejestr szybkości transmisji

Przykładowa definicja stałych
/* UART */ #define rULCON0 (*(volatile unsigned *)0x1d00000) #define rULCON1 (*(volatile unsigned *)0x1d04000) #define rUCON0 (*(volatile unsigned *)0x1d00004) #define rUCON1 (*(volatile unsigned *)0x1d04004) #define rUFCON0 (*(volatile unsigned *)0x1d00008) #define rUFCON1 (*(volatile unsigned *)0x1d04008) #define rUMCON0 (*(volatile unsigned *)0x1d0000c) #define rUMCON1 (*(volatile unsigned *)0x1d0400c) #define rUTRSTAT0 (*(volatile unsigned *)0x1d00010) #define rUTRSTAT1 (*(volatile unsigned *)0x1d04010) #define rUERSTAT0 (*(volatile unsigned *)0x1d00014) #define rUERSTAT1 (*(volatile unsigned *)0x1d04014) #define rUFSTAT0 (*(volatile unsigned *)0x1d00018) #define rUFSTAT1 (*(volatile unsigned *)0x1d04018) #define rUMSTAT0 (*(volatile unsigned *)0x1d0001c) #define rUMSTAT1 (*(volatile unsigned *)0x1d0401c) #define rUBRDIV0 (*(volatile unsigned *)0x1d00028) #define rUBRDIV1 (*(volatile unsigned *)0x1d04028)

Funkcje z biblioteki Embest IDE
/*44blib.c*/ void Delay(int time); //Watchdog Timer is used. void DelayMs(int ms_time); void DelayTime(int num); void *malloc(unsigned nbyte); void free(void *pt); void Port_Init(void); void Cache_Flush(void); void ChangeMemCon(unsigned *pMemCfg); void Uart_Select(int ch); void Uart_TxEmpty(int ch); void Uart_Init(int mclk,int baud); char Uart_Getch(void); char Uart_GetKey(void); int Uart_GetIntNum(void); void Uart_SendByte(int data); void Uart_Printf(char *fmt,...); void Uart_SendString(char *pt); void Timer_Start(int divider); //Watchdog Timer is used. int Timer_Stop(void); //Watchdog Timer is used. void Led_Display(int LedStatus); void Beep(int BeepStatus); void ChangePllValue(int m,int p,int s); void _Link(void);//memory usage void sys_init();// Interrupt,Port and UART

Wybrane funkcje obsługi UART
void Port_Init(void); void sys_init();// Interrupt,Port and UART void Uart_Select(int ch); void Uart_TxEmpty(int ch); void Uart_Init(int mclk,int baud); char Uart_Getch(void); char Uart_GetKey(void); int Uart_GetIntNum(void); void Uart_SendByte(int data); void Uart_Printf(char *fmt,...); void Uart_SendString(char *pt);

Inicjalizacja UART I static int whichUart=0; void Uart_Init(int mclk, int baud) { int i; if(mclk == 0) mclk=MCLK; rUFCON0=0x0; //FIFO disable rUFCON1=0x0; rUMCON0=0x0; rUMCON1=0x0; //UART0 rULCON0=0x3; //Normal,No parity,1 stop,8 bit rUCON0=0x245; //rx=edge,tx=level,disable timeout int.,enable rx error int.,normal,interrupt or polling rUBRDIV0=( (int)(mclk/16./baud + 0.5) -1 ); //UART1 rULCON1=0x3; rUCON1=0x245; rUBRDIV1=( (int)(mclk/16./baud + 0.5) -1 ); for(i=0;i<100;i++); }

Odbiór znaku char Uart_Getch(void) { if(whichUart==0) while(!(rUTRSTAT0 & 0x1)); //Receive data read return RdURXH0(); } else while(!(rUTRSTAT1 & 0x1)); //Receive data ready return rURXH1;

Wysłanie znaku I void Uart_SendByte(int data) { if(whichUart==0) if(data=='\n') while(!(rUTRSTAT0 & 0x2)); Delay(10); //because the slow response of hyper_terminal WrUTXH0('\r'); } while(!(rUTRSTAT0 & 0x2)); //Wait until THR is empty. Delay(10); WrUTXH0(data);

Wysłanie znaku II else { if(data=='\n') { while(!(rUTRSTAT1 & 0x2)); Delay(10); //because the slow response of hyper_terminal rUTXH1='\r'; } while(!(rUTRSTAT1 & 0x2)); //Wait until THR is empty. Delay(10); rUTXH1=data;

Struktura dla procesora AT91SAM7X256 wg. IAR I
// ***************************************************************************** // SOFTWARE API DEFINITION FOR Usart typedef struct _AT91S_USART { AT91_REG US_CR; // Control Register AT91_REG US_MR; // Mode Register AT91_REG US_IER; // Interrupt Enable Register AT91_REG US_IDR; // Interrupt Disable Register AT91_REG US_IMR; // Interrupt Mask Register AT91_REG US_CSR; // Channel Status Register AT91_REG US_RHR; // Receiver Holding Register AT91_REG US_THR; // Transmitter Holding Register AT91_REG US_BRGR; // Baud Rate Generator Register AT91_REG US_RTOR; // Receiver Time-out Register AT91_REG US_TTGR; // Transmitter Time-guard Register AT91_REG Reserved0[5]; // AT91_REG US_FIDI; // FI_DI_Ratio Register

Struktura dla procesora AT91SAM7X256 wg. IAR II
AT91_REG US_NER; // Nb Errors Register AT91_REG Reserved1[1]; // AT91_REG US_IF; // IRDA_FILTER Register AT91_REG Reserved2[44]; // AT91_REG US_RPR; // Receive Pointer Register AT91_REG US_RCR; // Receive Counter Register AT91_REG US_TPR; // Transmit Pointer Register AT91_REG US_TCR; // Transmit Counter Register AT91_REG US_RNPR; // Receive Next Pointer Register AT91_REG US_RNCR; // Receive Next Counter Register AT91_REG US_TNPR; // Transmit Next Pointer Register AT91_REG US_TNCR; // Transmit Next Counter Register AT91_REG US_PTCR; // PDC Transfer Control Register AT91_REG US_PTSR; // PDC Transfer Status Register } AT91S_USART, *AT91PS_USART;

Definicja wartości rejestrów AT91SAM7X256 wg. IAR II
// US_CR : (USART Offset: 0x0) Debug Unit Control Register #define AT91C_US_STTBRK ((unsigned int) 0x1 << 9) // (USART) Start Break #define AT91C_US_STPBRK ((unsigned int) 0x1 << 10) // (USART) Stop Break #define AT91C_US_STTTO ((unsigned int) 0x1 << 11) // (USART) Start Time-out #define AT91C_US_SENDA ((unsigned int) 0x1 << 12) // (USART) Send Address #define AT91C_US_RSTIT ((unsigned int) 0x1 << 13) // (USART) Reset Iterations #define AT91C_US_RSTNACK ((unsigned int) 0x1 << 14) // (USART) Reset Non Acknowledge #define AT91C_US_RETTO ((unsigned int) 0x1 << 15) // (USART) Rearm Time-out #define AT91C_US_DTREN ((unsigned int) 0x1 << 16) // (USART) Data Terminal ready Enable #define AT91C_US_DTRDIS ((unsigned int) 0x1 << 17) // (USART) Data Terminal ready Disable #define AT91C_US_RTSEN ((unsigned int) 0x1 << 18) // (USART) Request to Send enable #define AT91C_US_RTSDIS ((unsigned int) 0x1 << 19) // (USART) Request to Send Disable // US_MR : (USART Offset: 0x4) Debug Unit Mode Register #define AT91C_US_USMODE ((unsigned int) 0xF << 0) // (USART) Usart mode #define AT91C_US_USMODE_NORMAL ((unsigned int) 0x0) // (USART) Normal #define AT91C_US_USMODE_RS485 ((unsigned int) 0x1) // (USART) RS485 #define AT91C_US_USMODE_HWHSH ((unsigned int) 0x2) // (USART) Hardware Handshaking

Definicja wartości rejestrów AT91SAM7X256 wg. IAR II
#define AT91C_US_USMODE_MODEM ((unsigned int) 0x3) // (USART) Modem #define AT91C_US_USMODE_ISO7816_0 ((unsigned int) 0x4) // (USART) ISO7816 protocol: T = 0 #define AT91C_US_USMODE_ISO7816_1 ((unsigned int) 0x6) // (USART) ISO7816 protocol: T = 1 #define AT91C_US_USMODE_IRDA ((unsigned int) 0x8) // (USART) IrDA #define AT91C_US_USMODE_SWHSH ((unsigned int) 0xC) // (USART) Software Handshaking #define AT91C_US_CLKS ((unsigned int) 0x3 << 4) // (USART) Clock Selection (Baud Rate generator Input Clock #define AT91C_US_CLKS_CLOCK ((unsigned int) 0x0 << 4) // (USART) Clock #define AT91C_US_CLKS_FDIV1 ((unsigned int) 0x1 << 4) // (USART) fdiv1 #define AT91C_US_CLKS_SLOW ((unsigned int) 0x2 << 4) // (USART) slow_clock (ARM) #define AT91C_US_CLKS_EXT ((unsigned int) 0x3 << 4) // (USART) External (SCK) #define AT91C_US_CHRL ((unsigned int) 0x3 << 6) // (USART) Clock Selection (Baud Rate generator Input Clock #define AT91C_US_CHRL_5_BITS ((unsigned int) 0x0 << 6) // (USART) Character Length: 5 bits

Definicja wartości rejestrów AT91SAM7X256 wg. IAR III
#define AT91C_US_CHRL_6_BITS ((unsigned int) 0x1 << 6) // (USART) Character Length: 6 bits #define AT91C_US_CHRL_7_BITS ((unsigned int) 0x2 << 6) // (USART) Character Length: 7 bits #define AT91C_US_CHRL_8_BITS ((unsigned int) 0x3 << 6) // (USART) Character Length: 8 bits #define AT91C_US_SYNC ((unsigned int) 0x1 << 8) // (USART) Synchronous Mode Select #define AT91C_US_NBSTOP ((unsigned int) 0x3 << 12) // (USART) Number of Stop bits #define AT91C_US_NBSTOP_1_BIT ((unsigned int) 0x0 << 12) // (USART) 1 stop bit #define AT91C_US_NBSTOP_15_BIT ((unsigned int) 0x1 << 12) // (USART) Asynchronous (SYNC=0) 2 stop bits Synchronous (SYNC=1) 2 stop bits #define AT91C_US_NBSTOP_2_BIT ((unsigned int) 0x2 << 12) // (USART) 2 stop bits #define AT91C_US_MSBF ((unsigned int) 0x1 << 16) // (USART) Bit Order #define AT91C_US_MODE9 ((unsigned int) 0x1 << 17) // (USART) 9-bit Character length #define AT91C_US_CKLO ((unsigned int) 0x1 << 18) // (USART) Clock Output Select #define AT91C_US_OVER ((unsigned int) 0x1 << 19) // (USART) Over Sampling Mode #define AT91C_US_INACK ((unsigned int) 0x1 << 20) // (USART) Inhibit Non Acknowledge #define AT91C_US_DSNACK ((unsigned int) 0x1 << 21) // (USART) Disable Successive NACK

Definicja offsetu struktury AT91SAM7X256 wg. IAR I
// ***************************************************************************** // SOFTWARE API DEFINITION FOR Usart // *** Register offset in AT91S_USART structure *** #define US_CR ( 0) // Control Register #define US_MR ( 4) // Mode Register #define US_IER ( 8) // Interrupt Enable Register #define US_IDR (12) // Interrupt Disable Register #define US_IMR (16) // Interrupt Mask Register #define US_CSR (20) // Channel Status Register #define US_RHR (24) // Receiver Holding Register #define US_THR (28) // Transmitter Holding Register #define US_BRGR (32) // Baud Rate Generator Register #define US_RTOR (36) // Receiver Time-out Register #define US_TTGR (40) // Transmitter Time-guard Register #define US_FIDI (64) // FI_DI_Ratio Register #define US_NER (68) // Nb Errors Register #define US_IF (76) // IRDA_FILTER Register

Definicja offsetu struktury AT91SAM7X256 wg. IAR II
#define US_RPR (256) // Receive Pointer Register #define US_RCR (260) // Receive Counter Register #define US_TPR (264) // Transmit Pointer Register #define US_TCR (268) // Transmit Counter Register #define US_RNPR (272) // Receive Next Pointer Register #define US_RNCR (276) // Receive Next Counter Register #define US_TNPR (280) // Transmit Next Pointer Register #define US_TNCR (284) // Transmit Next Counter Register #define US_PTCR (288) // PDC Transfer Control Register #define US_PTSR (292) // PDC Transfer Status Register

Definicja wartości konf. AT91SAM7X256 wg. IAR I
// US_CR : (USART Offset: 0x0) Debug Unit Control Register #define AT91C_US_STTBRK (0x1 << 9) // (USART) Start Break #define AT91C_US_STPBRK (0x1 << 10) // (USART) Stop Break #define AT91C_US_STTTO (0x1 << 11) // (USART) Start Time-out #define AT91C_US_SENDA (0x1 << 12) // (USART) Send Address #define AT91C_US_RSTIT (0x1 << 13) // (USART) Reset Iterations #define AT91C_US_RSTNACK (0x1 << 14) // (USART) Reset Non Acknowledge #define AT91C_US_RETTO (0x1 << 15) // (USART) Rearm Time-out #define AT91C_US_DTREN (0x1 << 16) // (USART) Data Terminal ready Enable #define AT91C_US_DTRDIS (0x1 << 17) // (USART) Data Terminal ready Disable #define AT91C_US_RTSEN (0x1 << 18) // (USART) Request to Send enable #define AT91C_US_RTSDIS (0x1 << 19) // (USART) Request to Send Disable

Definicja wartości konf. AT91SAM7X256 wg. IAR II
// US_MR : (USART Offset: 0x4) Debug Unit Mode Register #define AT91C_US_USMODE (0xF << 0) // (USART) Usart mode #define AT91C_US_USMODE_NORMAL (0x0) // (USART) Normal #define AT91C_US_USMODE_RS485 (0x1) // (USART) RS485 #define AT91C_US_USMODE_HWHSH (0x2) // (USART) Hardware Handshaking #define AT91C_US_USMODE_MODEM (0x3) // (USART) Modem #define AT91C_US_USMODE_ISO7816_0 (0x4) // (USART) ISO7816 protocol: T = 0 #define AT91C_US_USMODE_ISO7816_1 (0x6) // (USART) ISO7816 protocol: T = 1 #define AT91C_US_USMODE_IRDA (0x8) // (USART) IrDA #define AT91C_US_USMODE_SWHSH (0xC) // (USART) Software Handshaking #define AT91C_US_CLKS (0x3 << 4) // (USART) Clock Selection (Baud Rate generator Input Clock #define AT91C_US_MAX_ITER ((unsigned int) 0x1 << 24) // (USART) Number of Repetitions #define AT91C_US_FILTER ((unsigned int) 0x1 << 28) // (USART) Receive Line Filter

Definicja wartości konf. AT91SAM7X256 wg. IAR III
// US_IER : (USART Offset: 0x8) Debug Unit Interrupt Enable Register #define AT91C_US_RXBRK ((unsigned int) 0x1 << 2) // (USART) Break Received/End of Break #define AT91C_US_TIMEOUT ((unsigned int) 0x1 << 8) // (USART) Receiver Time-out #define AT91C_US_ITERATION ((unsigned int) 0x1 << 10) // (USART) Max number of Repetitions Reached #define AT91C_US_NACK ((unsigned int) 0x1 << 13) // (USART) Non Acknowledge #define AT91C_US_RIIC ((unsigned int) 0x1 << 16) // (USART) Ring INdicator Input Change Flag #define AT91C_US_DSRIC ((unsigned int) 0x1 << 17) // (USART) Data Set Ready Input Change Flag #define AT91C_US_DCDIC ((unsigned int) 0x1 << 18) // (USART) Data Carrier Flag #define AT91C_US_CTSIC ((unsigned int) 0x1 << 19) // (USART) Clear To Send Input Change Flag

Definicja wartości konf. AT91SAM7X256 wg. IAR IV
// US_IDR : (USART Offset: 0xc) Debug Unit Interrupt Disable Register // US_IMR : (USART Offset: 0x10) Debug Unit Interrupt Mask Register // US_CSR : (USART Offset: 0x14) Debug Unit Channel Status Register #define AT91C_US_RI ((unsigned int) 0x1 << 20) // (USART) Image of RI Input #define AT91C_US_DSR ((unsigned int) 0x1 << 21) // (USART) Image of DSR Input #define AT91C_US_DCD ((unsigned int) 0x1 << 22) // (USART) Image of DCD Input #define AT91C_US_CTS ((unsigned int) 0x1 << 23) // (USART) Image of CTS Input #define AT91C_US_CLKS_CLOCK (0x0 << 4) // (USART) Clock #define AT91C_US_CLKS_FDIV1 (0x1 << 4) // (USART) fdiv1 #define AT91C_US_CLKS_SLOW (0x2 << 4) // (USART) slow_clock (ARM) #define AT91C_US_CLKS_EXT (0x3 << 4) // (USART) External (SCK) #define AT91C_US_CHRL (0x3 << 6) // (USART) Clock Selection (Baud Rate generator Input Clock #define AT91C_US_CHRL_5_BITS (0x0 << 6) // (USART) Character Length: 5 bits #define AT91C_US_CHRL_6_BITS (0x1 << 6) // (USART) Character Length: 6 bits #define AT91C_US_CHRL_7_BITS (0x2 << 6) // (USART) Character Length: 7 bits #define AT91C_US_CHRL_8_BITS (0x3 << 6) // (USART) Character Length: 8 bits #define AT91C_US_SYNC (0x1 << 8) // (USART) Synchronous Mode Select

Definicja wartości konf. AT91SAM7X256 wg. IAR V
#define AT91C_US_NBSTOP (0x3 << 12) // (USART) Number of Stop bits #define AT91C_US_NBSTOP_1_BIT (0x0 << 12) // (USART) 1 stop bit #define AT91C_US_NBSTOP_15_BIT (0x1 << 12) // (USART) Asynchronous (SYNC=0) 2 stop bits Synchronous (SYNC=1) 2 stop bits #define AT91C_US_NBSTOP_2_BIT (0x2 << 12) // (USART) 2 stop bits #define AT91C_US_MSBF (0x1 << 16) // (USART) Bit Order #define AT91C_US_MODE9 (0x1 << 17) // (USART) 9-bit Character length #define AT91C_US_CKLO (0x1 << 18) // (USART) Clock Output Select #define AT91C_US_OVER (0x1 << 19) // (USART) Over Sampling Mode #define AT91C_US_INACK (0x1 << 20) // (USART) Inhibit Non Acknowledge #define AT91C_US_DSNACK (0x1 << 21) // (USART) Disable Successive NACK #define AT91C_US_MAX_ITER (0x1 << 24) // (USART) Number of Repetitions #define AT91C_US_FILTER (0x1 << 28) // (USART) Receive Line Filter

Definicja wartości konf. AT91SAM7X256 wg. IAR VI
// US_IER : (USART Offset: 0x8) Debug Unit Interrupt Enable Register #define AT91C_US_RXBRK (0x1 << 2) // (USART) Break Received/End of Break #define AT91C_US_TIMEOUT (0x1 << 8) // (USART) Receiver Time-out #define AT91C_US_ITERATION (0x1 << 10) // (USART) Max number of Repetitions Reached #define AT91C_US_NACK (0x1 << 13) // (USART) Non Acknowledge #define AT91C_US_RIIC (0x1 << 16) // (USART) Ring INdicator Input Change Flag #define AT91C_US_DSRIC (0x1 << 17) // (USART) Data Set Ready Input Change Flag #define AT91C_US_DCDIC (0x1 << 18) // (USART) Data Carrier Flag #define AT91C_US_CTSIC (0x1 << 19) // (USART) Clear To Send Input Change Flag

Definicja wartości konf. AT91SAM7X256 wg. IAR VII
// US_IDR : (USART Offset: 0xc) Debug Unit Interrupt Disable Register // US_IMR : (USART Offset: 0x10) Debug Unit Interrupt Mask Register // US_CSR : (USART Offset: 0x14) Debug Unit Channel Status Register #define AT91C_US_RI (0x1 << 20) // (USART) Image of RI Input #define AT91C_US_DSR (0x1 << 21) // (USART) Image of DSR Input #define AT91C_US_DCD (0x1 << 22) // (USART) Image of DCD Input #define AT91C_US_CTS (0x1 << 23) // (USART) Image of CTS Input

Środowisko IAR – funkcje I
//* \fn AT91F_US_Baudrate //* \brief Calculate the baudrate //* Standard Asynchronous Mode : 8 bits , 1 stop , no parity #define AT91C_US_ASYNC_MODE ( AT91C_US_USMODE_NORMAL + \ AT91C_US_NBSTOP_1_BIT + \ AT91C_US_PAR_NONE + \ AT91C_US_CHRL_8_BITS + \ AT91C_US_CLKS_CLOCK )

Środowisko IAR – funkcje II
//* Standard External Asynchronous Mode : 8 bits , 1 stop , no parity #define AT91C_US_ASYNC_SCK_MODE ( AT91C_US_USMODE_NORMAL + \ AT91C_US_NBSTOP_1_BIT + \ AT91C_US_PAR_NONE + \ AT91C_US_CHRL_8_BITS + \ AT91C_US_CLKS_EXT )

Środowisko IAR – funkcje III
//* Standard Synchronous Mode : 8 bits , 1 stop , no parity #define AT91C_US_SYNC_MODE ( AT91C_US_SYNC + \ AT91C_US_USMODE_NORMAL + \ AT91C_US_NBSTOP_1_BIT + \ AT91C_US_PAR_NONE + \ AT91C_US_CHRL_8_BITS + \ AT91C_US_CLKS_CLOCK )

Środowisko IAR – funkcje VI
//* Standard ISO T=0 Mode : 8 bits , 1 stop , parity #define AT91C_US_ISO_READER_MODE ( AT91C_US_USMODE_ISO7816_0 + \ AT91C_US_CLKS_CLOCK +\ AT91C_US_NBSTOP_1_BIT + \ AT91C_US_PAR_EVEN + \ AT91C_US_CHRL_8_BITS + \ AT91C_US_CKLO +\ AT91C_US_OVER)

Środowisko IAR – funkcje V
//* Standard IRDA mode #define AT91C_US_ASYNC_IRDA_MODE ( AT91C_US_USMODE_IRDA + \ AT91C_US_NBSTOP_1_BIT + \ AT91C_US_PAR_NONE + \ AT91C_US_CHRL_8_BITS + \ AT91C_US_CLKS_CLOCK )

Środowisko IAR – funkcje VI
//* //* \fn AT91F_US_Baudrate //* \brief Caluculate baud_value according to the main clock and the baud rate __inline unsigned int AT91F_US_Baudrate ( const unsigned int main_clock, // \arg peripheral clock const unsigned int baud_rate) // \arg UART baudrate { unsigned int baud_value = ((main_clock*10)/(baud_rate * 16)); if ((baud_value % 10) >= 5) baud_value = (baud_value / 10) + 1; else baud_value /= 10; return baud_value; }

Środowisko IAR – funkcje VII
//* //* \fn AT91F_US_SetBaudrate //* \brief Set the baudrate according to the CPU clock __inline void AT91F_US_SetBaudrate ( AT91PS_USART pUSART, // \arg pointer to a USART controller unsigned int mainClock, // \arg peripheral clock unsigned int speed) // \arg UART baudrate { //* Define the baud rate divisor register pUSART->US_BRGR = AT91F_US_Baudrate(mainClock, speed); }

Środowisko IAR – funkcje VIII
//* //* \fn AT91F_US_SetTimeguard //* \brief Set USART timeguard __inline void AT91F_US_SetTimeguard ( AT91PS_USART pUSART, // \arg pointer to a USART controller unsigned int timeguard) // \arg timeguard value { //* Write the Timeguard Register pUSART->US_TTGR = timeguard ; }

Środowisko IAR – funkcje IX
//* //* \fn AT91F_US_EnableIt //* \brief Enable USART IT __inline void AT91F_US_EnableIt ( AT91PS_USART pUSART, // \arg pointer to a USART controller unsigned int flag) // \arg IT to be enabled { //* Write to the IER register pUSART->US_IER = flag; }

Środowisko IAR – funkcje X
//* //* \fn AT91F_US_DisableIt //* \brief Disable USART IT __inline void AT91F_US_DisableIt ( AT91PS_USART pUSART, // \arg pointer to a USART controller unsigned int flag) // \arg IT to be disabled { //* Write to the IER register pUSART->US_IDR = flag; }

Środowisko IAR – konfiguracja - funkcje I
//* //* \fn AT91F_US_Configure //* \brief Configure USART __inline void AT91F_US_Configure ( AT91PS_USART pUSART, // \arg pointer to a USART controller unsigned int mainClock, // \arg peripheral clock unsigned int mode , // \arg mode Register to be programmed unsigned int baudRate , // \arg baudrate to be programmed unsigned int timeguard ) // \arg timeguard to be programmed { //* Disable interrupts pUSART->US_IDR = (unsigned int) -1;

Środowisko IAR – konfiguracja - funkcje II
//* Reset receiver and transmitter pUSART->US_CR = AT91C_US_RSTRX | AT91C_US_RSTTX | AT91C_US_RXDIS | AT91C_US_TXDIS ; //* Define the baud rate divisor register AT91F_US_SetBaudrate(pUSART, mainClock, baudRate); //* Write the Timeguard Register AT91F_US_SetTimeguard(pUSART, timeguard); //* Clear Transmit and Receive Counters AT91F_PDC_Open((AT91PS_PDC) &(pUSART->US_RPR)); //* Define the USART mode pUSART->US_MR = mode ; }

Środowisko IAR – funkcje XI
//* //* \fn AT91F_US_EnableRx //* \brief Enable receiving characters __inline void AT91F_US_EnableRx ( AT91PS_USART pUSART) // \arg pointer to a USART controller { //* Enable receiver pUSART->US_CR = AT91C_US_RXEN; }

Środowisko IAR – funkcje XII
//* //* \fn AT91F_US_EnableTx //* \brief Enable sending characters __inline void AT91F_US_EnableTx ( AT91PS_USART pUSART) // \arg pointer to a USART controller { //* Enable transmitter pUSART->US_CR = AT91C_US_TXEN; }

Środowisko IAR – funkcje XIII
//* //* \fn AT91F_US_ResetRx //* \brief Reset Receiver and re-enable it __inline void AT91F_US_ResetRx ( AT91PS_USART pUSART) // \arg pointer to a USART controller { //* Reset receiver pUSART->US_CR = AT91C_US_RSTRX; //* Re-Enable receiver pUSART->US_CR = AT91C_US_RXEN; }

Środowisko IAR – funkcje XIV
//* //* \fn AT91F_US_ResetTx //* \brief Reset Transmitter and re-enable it __inline void AT91F_US_ResetTx ( AT91PS_USART pUSART) // \arg pointer to a USART controller { //* Reset transmitter pUSART->US_CR = AT91C_US_RSTTX; //* Enable transmitter pUSART->US_CR = AT91C_US_TXEN; }

Środowisko IAR – funkcje XV
//* //* \fn AT91F_US_DisableRx //* \brief Disable Receiver __inline void AT91F_US_DisableRx ( AT91PS_USART pUSART) // \arg pointer to a USART controller { //* Disable receiver pUSART->US_CR = AT91C_US_RXDIS; }

Środowisko IAR – funkcje XVI
//* //* \fn AT91F_US_DisableTx //* \brief Disable Transmitter __inline void AT91F_US_DisableTx ( AT91PS_USART pUSART) // \arg pointer to a USART controller { //* Disable transmitter pUSART->US_CR = AT91C_US_TXDIS; }

Środowisko IAR – funkcje zamknięcie - I
//* //* \fn AT91F_US_Close //* \brief Close USART: disable IT disable receiver and transmitter, close PDC __inline void AT91F_US_Close ( AT91PS_USART pUSART) // \arg pointer to a USART controller { //* Reset the baud rate divisor register pUSART->US_BRGR = 0 ; //* Reset the USART mode pUSART->US_MR = 0 ;

Środowisko IAR – funkcje zamknięcie - II
//* Reset the Timeguard Register pUSART->US_TTGR = 0; //* Disable all interrupts pUSART->US_IDR = 0xFFFFFFFF ; //* Abort the Peripheral Data Transfers AT91F_PDC_Close((AT91PS_PDC) &(pUSART->US_RPR)); //* Disable receiver and transmitter and stop any activity immediately pUSART->US_CR = AT91C_US_TXDIS | AT91C_US_RXDIS | AT91C_US_RSTTX | AT91C_US_RSTRX ; }

Środowisko IAR – funkcje XVII
//* //* \fn AT91F_US_TxReady //* \brief Return 1 if a character can be written in US_THR __inline unsigned int AT91F_US_TxReady ( AT91PS_USART pUSART ) // \arg pointer to a USART controller { return (pUSART->US_CSR & AT91C_US_TXRDY); }

Środowisko IAR – funkcje XVIII
//* //* \fn AT91F_US_RxReady //* \brief Return 1 if a character can be read in US_RHR __inline unsigned int AT91F_US_RxReady ( AT91PS_USART pUSART ) // \arg pointer to a USART controller { return (pUSART->US_CSR & AT91C_US_RXRDY); }

Środowisko IAR – funkcje XIX
//* //* \fn AT91F_US_Error //* \brief Return the error flag __inline unsigned int AT91F_US_Error ( AT91PS_USART pUSART ) // \arg pointer to a USART controller { return (pUSART->US_CSR & (AT91C_US_OVRE | // Overrun error AT91C_US_FRAME | // Framing error AT91C_US_PARE)); // Parity error }

Środowisko IAR – funkcje XX
//* //* \fn AT91F_US_PutChar //* \brief Send a character,does not check if ready to send __inline void AT91F_US_PutChar ( AT91PS_USART pUSART, int character ) { pUSART->US_THR = (character & 0x1FF); }

Środowisko IAR – funkcje XXI
//* //* \fn AT91F_US_GetChar //* \brief Receive a character,does not check if a character is available __inline int AT91F_US_GetChar ( const AT91PS_USART pUSART) { return((pUSART->US_RHR) & 0x1FF); }

Środowisko IAR – funkcje – nadawanie ramki I
//* //* \fn AT91F_US_SendFrame //* \brief Return 2 if PDC has been initialized with Buffer and Next Buffer, 1 if PDC has been initializaed with Next Buffer, 0 if PDC is busy __inline unsigned int AT91F_US_SendFrame( AT91PS_USART pUSART, char *pBuffer, unsigned int szBuffer, char *pNextBuffer, unsigned int szNextBuffer ) { return AT91F_PDC_SendFrame( (AT91PS_PDC) &(pUSART->US_RPR), pBuffer, szBuffer, pNextBuffer, szNextBuffer); }

Środowisko IAR – funkcje – odbiór ramki I
//* //* \fn AT91F_US_ReceiveFrame //* \brief Return 2 if PDC has been initialized with Buffer and Next Buffer, 1 if PDC has been initializaed with Next Buffer, 0 if PDC is busy __inline unsigned int AT91F_US_ReceiveFrame ( AT91PS_USART pUSART, char *pBuffer, unsigned int szBuffer, char *pNextBuffer, unsigned int szNextBuffer ) { return AT91F_PDC_ReceiveFrame( (AT91PS_PDC) &(pUSART->US_RPR), pBuffer, szBuffer, pNextBuffer, szNextBuffer); }

Środowisko IAR – funkcje – IRDA I
//* //* \fn AT91F_US_SetIrdaFilter //* \brief Set the value of IrDa filter tregister __inline void AT91F_US_SetIrdaFilter ( AT91PS_USART pUSART, unsigned char value ) { pUSART->US_IF = value; }

Przerwanie - I // Include Standard LIB files #include "../srcIAR/project.h" #define USART_INTERRUPT_LEVEL 7 #define AT91_BAUD_RATE static const char atmel_header[]= { "\n\r *** ATMEL Usart IRQ ***\n\r" "Copyright (C) 2005 ATMEL Corporations Version: 1.0\n\r" }; //* \fn AT91F_US_Baudrate //* \brief Calculate the baudrate //* Standard Asynchronous Mode : 8 bits , 1 stop , no parity #define AT91C_US_ASYNC_MODE ( AT91C_US_USMODE_NORMAL + \ AT91C_US_NBSTOP_1_BIT + \ AT91C_US_PAR_NONE + \ AT91C_US_CHRL_8_BITS + \ AT91C_US_CLKS_CLOCK )

Przerwanie - II //* Internal Function //* //* Function Name : Usart_c_irq_handler //* Object : C handler interrupt function calAT91B_LED by the interrupts //* assembling routine //* Input Parameters : <RTC_pt> time rtc descriptor //* Output Parameters : increment count_timer0_interrupt

Przerwanie - III void Usart_c_irq_handler(void) {
AT91PS_USART USART_pt = AT91C_BASE_US0; unsigned int status; //* get Usart status register status = USART_pt->US_CSR; if ( status & AT91C_US_RXRDY){ //* Get byte and send AT91F_US_PutChar (USART_pt, AT91F_US_GetChar(USART_pt)); } if ( status & AT91C_US_OVRE) { //* clear US_RXRDY AT91F_US_GetChar(USART_pt); AT91F_US_PutChar (USART_pt, 'O'); //* Check error if ( status & AT91C_US_PARE) { AT91F_US_PutChar (USART_pt, 'P');

Przerwanie - IV if ( status & AT91C_US_FRAME) { AT91F_US_PutChar (USART_pt, 'F'); } if ( status & AT91C_US_TIMEOUT){ USART_pt->US_CR = AT91C_US_STTTO; AT91F_US_PutChar (USART_pt, 'T'); //* Reset the satus bit USART_pt->US_CR = AT91C_US_RSTSTA;

Inicjalizacja - I //* External Function //* //* Function Name : Usart_init //* Object : USART initialization //* Input Parameters : none //* Output Parameters : TRUE

Inicjalizacja - II void Usart_init ( void ) //* Begin { AT91PS_USART COM0 = AT91C_BASE_US0; //* Configure PIO controllers to periph mode AT91F_PIO_CfgPeriph( AT91C_BASE_PIOA, ((unsigned int) AT91C_PA0_RXD0 ) | ((unsigned int) AT91C_PA1_TXD0 ) | ((unsigned int) AT91C_PA3_RTS0 ) | ((unsigned int) AT91C_PA4_CTS0 ), // Peripheral A 0); // Peripheral B

Inicjalizacja - III // First, enable the clock of the USART
AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PMC, 1 << AT91C_ID_US0 ) ; // Usart Configure AT91F_US_Configure (COM0, AT91B_MCK, AT91C_US_ASYNC_MODE, AT91_BAUD_RATE, 0); // Enable usart COM0->US_CR = AT91C_US_RXEN | AT91C_US_TXEN; //* Enable USART IT error and RXRDY AT91F_US_EnableIt(COM0,AT91C_US_TIMEOUT | AT91C_US_FRAME | AT91C_US_OVRE |AT91C_US_RXRDY);

Inicjalizacja - IV //* open Usart 1 interrupt AT91F_AIC_ConfigureIt ( AT91C_BASE_AIC, AT91C_ID_US0, USART_INTERRUPT_LEVEL,AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL, Usart_c_irq_handler); AT91F_AIC_EnableIt (AT91C_BASE_AIC, AT91C_ID_US0); AT91F_US_PutChar (COM0,'X'); AT91F_US_SendFrame(COM0,(char *)atmel_header,sizeof(atmel_header),0,0); //* End }

Przerwanie – całość I ; ; ?RESET ; Reset Vector. ; Normally, segment INTVEC is linked at address 0. ; For debugging purposes, INTVEC may be placed at other addresses. ; A debugger that honors the entry point will start the ; program in a normal way even if INTVEC is not at address 0. PROGRAM ?RESET ;- Begins a program module RSEG INTRAMEND_REMAP ;- Begins a relocatable segment RSEG ICODE:CODE (2) ;- Begins a relocatable segment ; corresponding address is 32-bit aligned CODE32 ;- Always ARM mode after reset ORG 0 ;- Sets the location counter ; corresponds to the RESET vector address

Przerwanie – całość II ; ;- Exception vectors ;- These vectors can be read at address 0 or at RAM address ;- They ABSOLUTELY requires to be in relative addresssing mode in order to ;- guarantee a valid jump. For the moment, all are just looping. ;- If an exception occurs before remap, this would result in an infinite loop. ;- To ensure if a exeption occurs before start application to infinite loop. reset B InitReset ; 0x00 Reset handler undefvec: B undefvec ; 0x04 Undefined Instruction swivec: B swivec ; 0x08 Software Interrupt

Przerwanie – całość III
pabtvec: B pabtvec ; 0x0C Prefetch Abort dabtvec: B dabtvec ; 0x10 Data Abort rsvdvec: B rsvdvec ; 0x14 reserved irqvec: B IRQ_Handler_Entry ; 0x18 IRQ fiqvec: ; 0x1c FIQ

Przerwanie – całość IV ; ;- Function : FIQ_Handler_Entry ;- Treatments : FIQ Controller Interrupt Handler. ;- R8 is initialize in Cstartup ;- Called Functions : None only by FIQ FIQ_Handler_Entry: ;- Switch in SVC/User Mode to allow User Stack access for C code ; because the FIQ is not yet acknowledged ;- Save and r0 in FIQ_Register mov r9,r0 ldr r0 , [r8, #AIC_FVR] msr CPSR_c,#I_BIT | F_BIT | ARM_MODE_SVC ;- Save scratch/used registers and LR in User Stack stmfd sp!, { r1-r3, r12, lr}

Przerwanie – całość V ;- Branch to the routine pointed by the AIC_FVR mov r14, pc bx r0 ;- Restore scratch/used registers and LR from User Stack ldmia sp!, { r1-r3, r12, lr} ;- Leave Interrupts disabled and switch back in FIQ mode msr CPSR_c, #I_BIT | F_BIT | ARM_MODE_FIQ ;- Restore the R0 ARM_MODE_SVC register mov r0,r9 ;- Restore the Program Counter using the LR_fiq directly in the PC subs pc,lr,#4

Przerwanie – całość VI ; ;- Manage exception: The exception must be ensure in ARM mode ;- Function : IRQ_Handler_Entry ;- Treatments : IRQ Controller Interrupt Handler. ;- Called Functions : None By IRQ interrupt IRQ_Handler_Entry: ; ;- Manage Exception Entry ;- Adjust and save LR_irq in IRQ stack sub lr, lr, #4 stmfd sp!, {lr}

Przerwanie – całość VII
;- Save r0 and SPSR (need to be saved for nested interrupt) mrs r14, SPSR stmfd sp!, {r0,r14} ;- Write in the IVR to support Protect Mode ;- No effect in Normal Mode ;- De-assert the NIRQ and clear the source in Protect Mode ldr r14, =AT91C_BASE_AIC ldr r0 , [r14, #AIC_IVR] str r14, [r14, #AIC_IVR] ;- Enable Interrupt and Switch in Supervisor Mode msr CPSR_c, #ARM_MODE_SVC ;- Save scratch/used registers and LR in User Stack stmfd sp!, { r1-r3, r12, r14}

Przerwanie – całość VIII
; ;- Branch to the routine pointed by the AIC_IVR mov r14, pc bx r0 ;- Manage Exception Exit ;- Restore scratch/used registers and LR from User Stack ldmia sp!, { r1-r3, r12, r14} ;- Disable Interrupt and switch back in IRQ mode msr CPSR_c, #I_BIT | ARM_MODE_IRQ

Przerwanie – całość IX ;- Mark the End of Interrupt on the AIC ldr r14, =AT91C_BASE_AIC str r14, [r14, #AIC_EOICR] ;- Restore SPSR_irq and r0 from IRQ stack ldmia sp!, {r0,r14} msr SPSR_cxsf, r14 ;- Restore adjusted LR_irq from IRQ stack directly in the PC ldmia sp!, {pc}^

Przerwanie – całość X InitReset: ; ;- Low level Init is performed in a C function: AT91F_LowLevelInit ;- Init Stack Pointer to a valid memory area before calling AT91F_LowLevelInit ;- Retrieve end of RAM address __iramend EQU SFB(INTRAMEND_REMAP) ;- Segment begin EXTERN AT91F_LowLevelInit ;- Temporary stack in internal RAM for Low Level Init execution ldr r13,=__iramend ldr r0,=AT91F_LowLevelInit mov lr, pc bx r0 ;- Branch on C function (interworking)

Przerwanie – całość XI ; ;- Top of Stack Definition ;- Interrupt and Supervisor Stack are located at the top of internal memory in ;- order to speed the exception handling context saving and restoring. ;- ARM_MODE_SVC (Application, C) Stack is located at the top of the external ;- memory. ; IRQ_STACK_SIZE = 3 words to be saved per interrupt priority level IRQ_STACK_SIZE EQU (3*8*4) ARM_MODE_FIQ EQU 0x11 ARM_MODE_IRQ EQU 0x12 ARM_MODE_SVC EQU 0x13 I_BIT EQU 0x80 F_BIT EQU 0x40

Przerwanie – całość XII
; ;- Setup the stack for each mode ldr r0, =__iramend ;- Set up Fast Interrupt Mode and set FIQ Mode Stack msr CPSR_c, #ARM_MODE_FIQ | I_BIT | F_BIT ;- Init the FIQ register ldr r8, =AT91C_BASE_AIC ;- Set up Interrupt Mode and set IRQ Mode Stack msr CPSR_c, #ARM_MODE_IRQ | I_BIT | F_BIT mov r13, r0 ; Init stack IRQ sub r0, r0, #IRQ_STACK_SIZE ;- Enable interrupt & Set up Supervisor Mode and set Supervisor Mode Stack msr CPSR_c, #ARM_MODE_SVC mov r13, r0

Przerwanie – całość XIII
; ; Initialize segments. ; __segment_init is assumed to use ; instruction set and to be reachable by BL from the ICODE segment ; (it is safest to link them in segment ICODE). EXTERN __segment_init ldr r0,=__segment_init mov lr, pc bx r0 ;- Branch on C function (interworking)

Przerwanie – całość XIV
; ;- Branch on C code Main function (with interworking) EXTERN main PUBLIC __main ?jump_to_main: ldr lr,=?call_exit ldr r0,=main __main: bx r0 ;- Branch on C function (interworking)

Przerwanie – całość XV ; ;- Loop for ever ;- End of application. Normally, never occur. ;- Could jump on Software Reset ( b reset). ?call_exit: End b End

Przerwanie – całość XVI
; ;- Exception Vectors PUBLIC AT91F_Default_FIQ_handler PUBLIC AT91F_Default_IRQ_handler PUBLIC AT91F_Spurious_handler CODE32 ; Always ARM mode after exeption AT91F_Default_FIQ_handler b AT91F_Default_FIQ_handler AT91F_Default_IRQ_handler b AT91F_Default_IRQ_handler AT91F_Spurious_handler b AT91F_Spurious_handler ENDMOD ;- Terminates the assembly of the current module END ;- Terminates the assembly of the last module in a file

EIA 232 poziomy napięć

EIA 422 I

EIA 422 II EIA/TIA-422 define a Balanced (differential) interface; specifying a single, unidirectional driver with multiple receivers (up to 32). RS-422 will support Point-to-Point, Multi-Drop circuits, but not Multi-Point [EIA485]. EIA-485 devices may be used in 422 circuits, but EIA-422 may not be used in 485 circuits (because of the lack of an Enable line). EIA422 is the differential "brother" to EIA423. One application note indicated that the combination of cable length (in meters) and data signaling rate (in bps) for RS422 should not exceed 108. The example provided a maximum speed of 200kbps with a maximum cable length of 500 meter [500 x 200,000]. An EIA-422 driver can support up to 10 loads, at 4K W per load.

EIA 422 III Circuit grounding is not shown is in either of the RS422 or RS485 circuits. However, the circuits should be grounded. The drivers and receivers should be connected directly to circuit ground. The circuit ground should be connected to chassis ground via a 100 ohm resistor. If the far-end circuit resides in another chassis, then the two circuit ground should be connected together via a 100 ohm resistor at each end. For additional ESD protection TransZorb [back-to-back] diodes may be added between the input/output lines and ground. Cabling is not specified in RS422 or RS485, but a rule of thumb is listed above for 24 AWG twisted pair copper wire with 16pF/ft. Refer to 24AWG Attenuation vs Frequency Chart. Cabling standards are listed lower down the page. The common name for this interface is RS422.

EIA 422 Pull up pull down I The Pullup/Down Resistors (Idle-line failsafe) are used to keep the +/- inputs of the Receiver(s) inputs at a minimum of 200mV differential. Normally required once the system has reached it's quiescent state, when no drivers are driving the bus. Only one end of the bus requires the resistor network. The resistor values are dictated by four factors: The input impedance of the receivers (between 5K and 90K ~ check the data sheet), The number of loads, the termination resistance 60 ohms (120 ohms per side), and the required (turn-on) current of the receivers. Many (on-line) App-notes use 12K ohms as an input impedance, 60 ohms (as a termination), 3.5 mA as the minimum 'load' current, and 10 loads.

EIA 422 Pull up pull down II Using these values {Check the data sheets for the real values!}: Number of loads (10) x 12KW ~ 1200W {That's ten 12Kohm resistors in parallel, 12K//10 loads} Line Termination ~ 60 ohms {120 ohms at each side of the link, in parallel, 120//120} Taking 1200 in parallel with 60 ohms gives 57 ohms Turn-On current ~ 3.5 mA {check the data sheet for the device used} The required load is 5volts / 3.5mA, which results in a load impedance of (around) 1428 ohms. Subtract 57W which is already present leaves; 1371W. Placing half on the +5 volts line and the other on the ground line, gives 675W per resistor / per supply. The nearest 5% standard value is 680W placed between both the 'A' line and +V connection and the 'B' line and the GND connection will produce < 3.5 mA (turn-on current}

Prędkości transmisji V.35/RS449 Max length Data Rate Cable Length
2 Mb/sec Meters 1 Mb/sec Meters 512 Kb/sec Meters 256 Kb/sec Meters 128 Kb/sec Meters 56 Kb/sec Meters 1.2 Kb/sec Meters

EIA 423 I

EIA 423 II

EIA 423 III

EIA 423 IV

EIA 423 V EIA/TIA-423 Unbalanced (Single-Ended) interface; specifies a single, unidirectional driver with multiple receivers (up to 10). "..Specifies the electrical characteristics of the unbalanced voltage digital interface circuit, normally implemented in integrated circuit technology, that may be employed when specified for the interchange of serial binary signals between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) or in any point-to-point interconnection of serial binary signals between digital equipment." 'Telecommunications Industry Association' EIA-423 is used in EIA-449 and EIA530, both of which define the cabling and pin-out to form a complete interface. As EIA-423 does not define a cable.

EIA 423 VI Normally EIA422 and RS-423 systems may not be connected together. EIA-449 cabling of 422 sends and receives data as differential pairs and control signal as single-ended, but for 423 cabling it sends and receives single-ended data and control signals. Receiving the single ended signal in 423 is accomplished by grounding the 'B' side of the differential receiver at the connector. So if the system follows the EIA-449 (cabling) specification than one (B) side of the differential receiver of the 423 side will be grounded at the connector forcing the differential driver on the 422 side to drive ground. The EIA422 side also uses a termination resistor between the ends of its differential receiver, providing a serious 120 ohm short to ground for the 423 driver.

EIA 423 VII If the systems were to be connected together (with out regard for RS499) than the system would revert to EIA423 (single-ended) distance and data rate ~ Only because the driver on the RS423 side is single ended, while the receiver on the RS422 side would receive the single-ended 423 signal and ground on its differential pair. How ever because 423 and 422 use the same receiver chip; going from 422 to 423 provides a differential path.

EIA II

EIA 485 I

EIA 485 II EIA-485 [TIA-485] Balanced (differential) interface; defines the Physical layer, signaling protocol is not defined. EIA485 is also called the RS485 standard, but the term RS485 is out-dated. EIA-485 specifies bidirectional, half-duplex data transmission. Up to 32 transmitters and 32 receivers may be interconnected in any combination, including one driver and multiple receivers (multi-drop), or one receiver and multiple drivers. The maximum of 32 devices is defined based on the Unit Load [UL] of each device [12K ohms]. The maximum devices on the net may be increased if the devices represent less then the UL [fractional unit load]. A number of devices are being produced which represent 1/4 or 1/8 the unit load. A maximum of 256 device could exist on the bus when each is at 1/8 the UL [96k ohms]. Repeaters may be used to extend the net to any number of devices. ProfiBus defines an RS-485 type bus using repeaters.

EIA 485 III EIA-485 requires a 120 Ohm line impedance (normally Shielded Twisted pair 'STP'), 120W (10%, 1/2 watt) terminations at both ends of the line (at the Receivers). Pull-up/Pull-down resistors (Idle-line failsafe) at one end of the 485 bus may be used to bring the line voltage to a steady state (200mV) value at the end of a transmission; when all drivers are in the passive state. No maximum bus length is given for RS485, but ends up around 1200 meters at 200kbps or 50 meters at 10Mbps. The speed of the system and distance between devices is determined in large amount by the inter-connecting cable. Single board solutions may be hooked up as shown, but chassis to chassis systems require a common ground connection to run between the driver and receiver. A number of specifications use EIA-485 as the electrical standard, including SCSI-2, SCSI-3, BitBus, and Profibus.

EIA 485 VI EIA/TIA-422 define a Balanced (differential) interface; specifying a single, unidirectional driver with multiple receivers (up to 32). RS-422 will support Point-to-Point, Multi-Drop circuits, but not Multi-Point [EIA485]. EIA-485 devices may be used in 422 circuits, but EIA-422 may not be used in 485 circuits (because of the lack of an Enable line). EIA422 is the differential "brother" to EIA423. One application note indicated that the combination of cable length (in meters) and data signaling rate (in bps) for RS422 should not exceed 108. The example provided a maximum speed of 200kbps with a maximum cable length of 500 meter [500 x 200,000]. An EIA-422 driver can support up to 10 loads, at 4K W per load This page provides two examples of RS485 fault protection.

EIA 485 pull up pull down I The Pullup/Down Resistors (Idle-line failsafe) are used to keep the +/- inputs of the Receiver(s) inputs at a minimum of 200mV differential. Normally required once the system has reached it's quiescent state, when no drivers are driving the bus. Only one end of the bus requires the resistor network. The resistor values are dictated by four factors: The input impedance of the receivers (between 5K and 90K ~ check the data sheet), The number of loads, the termination resistance 60 ohms (120 ohms per side), and the required (turn-on) current of the receivers. Many (on-line) App-notes use 12K ohms as an input impedance, 60 ohms (as a termination), 3.5 mA as the minimum 'load' current, and 10 loads. Using these values {Check the data sheets for the real values!}:

EIA 485 pull up pull down II ..... Number of loads (10) x 12KW ~ 1200W {That's ten 12Kohm resistors in parallel, 12K//10 loads} Line Termination ~ 60 ohms {120 ohms at each side of the link, in parallel, 120//120} Taking 1200 in parallel with 60 ohms gives 57 ohms Turn-On current ~ 3.5 mA {check the data sheet for the device used} The required load is 5volts / 3.5mA, which results in a load impedance of (around) 1428 ohms. Subtract 57W which is already present leaves; 1371W. Placing half on the +5 volts line and the other on the ground line, gives 675W per resistor / per supply. The nearest 5% standard value is 680W placed between both the 'A' line and +V connection and the 'B' line and the GND connection will produce < 3.5 mA (turn-on current}

EIA 485 okablowanie RS422 and RS485 do not define cabling or connector information. RS449 and RS530 [listed below] are two common cabling specifications which are used with the RS422/485 electrical standards that do define the type of RS485 Cable/RS485 Connector. Use 24 AWG twisted pair copper wire with 16pF/ft for cables. Maximum cable length is determined by the combination of cable length (in meters) and data signaling rate (in bps). RS422 should not exceed 108 for length x bps. The example provided a maximum speed of 200kbps with a maximum cable length of 500 meter [500 x 200,000]. Refer to 24AWG Attenuation vs Frequency Chart.

EIA 485 Odporność I

EIA 485 Odporność II

Porównanie

EIA 644 I

EIA 644 II EIA/TIA-644 Balanced (differential) interface [LVDS]; defines the Electrical layer (Receiver and Transmitter) only. Designed with an output voltage swing of 350mV at better then 400Mbps into a 100 ohm load, across a distance of about 10 meters. LVDS is only an Electrical spec - to be referenced by other specifications, it may be used with either a cable or PWB design. The type of cable determines cable length; Category 3 (CAT3) for 10m in length, CAT5 for longer runs (~20 100Mbps, ~50 50Mbps, ~100 10Mbps). Ribbon cable may be used for sub meter runs. Also listed under IEEE EIA-644 [LVDS] should not be confused with other (higher speed) Low-Voltage Differential circuits; ECL, PECL, LVPECL, or CML, all of which also use the term LVDS.

EIA 644 III LVDS [EIA-644], Low Voltage Differential Signaling; 3.5mA drive, at 655Mbps max, Point-to-Point BLVDS Bus LVDS, [Proprietary] 10mA drive designed to handle mulit-card low impedance backplane applications [One bus driver]. M-LVDS Multipoint LVDS [EIA-899], Addresses double terminated bus configurations also extends the common-mode range to +/-2 V. 11mA drive at 500Mbps max, 200/300Mbps typical for Multi-point. GLVDS Ground referenced LVDS, Places the driver output voltage offset closer to ground potential. LVDM Low Voltage Differential Signaling Multi-Point, [Proprietary], 8mA with one bus driver.

PECL to LVDS Conversion LVPECL to LVDS Conv.

Porównanie EIA 644

Modbus I Systemy automatyki przemysłowej, firma MODICON, 1979
Przyjęty jako standard inżynierski przez wielu producentów Powołano organizację kontrolującą rozwój standardu Standard jawny Pierwotnie – protokół realizowany na bazie magistrali RS485 Rejestracja jako standard IEC

Modbus II Obecna specyfikacja zawiera rozdzielne standardy warstwy aplikacji Modbus oraz warstwy łącza danych i fizycznej Możliwość realizacji na bazie różnych interfejsów – EIA232 / EIA485 – TCP / IP (Ethernet) – port 502 – High speed token passing network HDLC – protokół Modbus Plus Obejmuje możliwość enkapsulacji danych nie objętych protokołem – Współpraca z innymi systemami – np. CANopen – Współpraca z Gateway’ami

Modbus III Sygnalizacja błędów / zabezpieczanie przesyłanych komunikatów przed błędami Potwierdzanie wykonywania rozkazów Mechanizmy zabezpieczające przed zawieszeniem systemu Standard zawiera zgodne z notacją UML grafy stanów funkcji urządzeń Modbus Standard zawiera specyfikację elementów mechanicznych (złącza, kolory kabli) Standard zaleca sposób sygnalizacji transmisji diodą LED

Przykład sieci modbus

Ramka Modbus

Transakcja bez błędów

Transakcja – odpowiedź na wyjatek

Ethernet – IEEE802

A drawing of the first Ethernet system by Bob Metcalfe

Prehistoria Experimental Ethernet (1976) Original Ethernet (1982)
“Ethernet: Distributed Packet Switching for Local Computer Networks”; Metcalfe & Boggs, Xerox PARC Ethernet protocol definition ALOHA packet-based network access protocol over a wired shared medium 3 Mb/s operation Original Ethernet (1982) “The Ethernet Blue Book”; Digital, Intel, Xerox (DIX) 10Mb/s operation based on the Xerox PARC concepts

Dawna historia First IEEE Standard (1985) 10BASE-T (1990)
10 Mb/s operation over a shared medium Based on the “Ethernet Blue Book” Shared bus topology 10BASE-T (1990) 10 Mb/s half-duplex operation over Unshielded Twisted Pair (UTP) cables Star topology Removed the cabling infrastructure constraint from network deployment

Wiek średni Fast Ethernet (1995) Full Duplex Ethernet (1997)
Scaled the operating speed of Ethernet by an order of magnitude (take one!) 100 Mb/s half-duplex operation over: UTP BASE-T Multimode fiber (MMF) BASE-F Full Duplex Ethernet (1997) Speed-independent Ethernet protocol enhancement Relies on the full duplex nature of the physical link Star topology Provides dedicated bandwidth to end nodes Potentially doubles the link throughput

Historia niedawna I Gigabit Ethernet (1998/1999)
Scaled the operating speed of Ethernet by another order of magnitude (take two!!) Supports both half-duplex and full-duplex operation Only full-duplex has been deployed 1000 Mb/s operation over: UTP BASE-T MMF BASE-SX Single-mode fiber (SMF) BASE-LX Coax BASE-CX

Historia niedawna II Link Aggregation (2000) A.K.A. Trunking
Speed-independent Ethernet protocol enhancement Allows to configure multiple physical links into one logical link Unlimited scaling of network pipes Benefits realized only in environments where lots of networking flows are aggregated

Zasilanie w Ethernecie
Power Over Ethernet (2003) Provides a limited amount of DC power (~15W) to network attached devices Interoperable with the installed base Useful for environments where power is at premium or is hard to get to Wireless hubs Mobile devices (PDAs/laptops) Sensors Industrial applications

Historia niedawna III Ethernet in the First Mile (2004)
Cheapest/fastest solution to the “last mile problem” in the access space Phone lines: 2 Mbps – 10 Mbps dedicated (full duplex) VDSL-based Fiber: 1 Gbps shared among customers Based on a new fiber deployment topology for Passive Optical Networks (PONs)

Aktualnie I 10 Gigabit Ethernet (2002/2006)
Scaled the operating speed of Ethernet by yet another order of magnitude (take three!!) Supports full-duplex operation only Expands the application space of Ethernet to Wide Area Networks (WANs) A simplified SONET/SDH framer (WIS) provides data rate and transmission format compatibility with existing SONET transmission networks

Aktualnie II 10 Gigabit Ethernet (2002/2006) – continued Data Rates
10,000 Mb/s for LAN applications 9, Mb/s (OC-192) for WAN applications Media SMF GBASE-LR, -ER MMF GBASE-SR, -LX4, -LRM UTP GBASE-T Coax GBASE-CX4 FR4 backplanes GBASE-KX4, -KR

Formaty ramek – Ethernet DIX
Pole typu zawiera: 0x0600 XNS (Xerox) 0x0800 IP (the Internet protocol) 0x6003 DECNET Brak typów z wartościami poniżej 1500 (0x05DC – 0x0600=1536)

Formaty ramek – 802.3 Każdy pakiet Ethernet z długością poniżej 1500 jest traktowany jako 802.3 Każdy pakiet Ethernet z polem długości powyżej 1500 jest traktowany jako DIX Jako zastępstwo typu w traktowany jest nagłówek 802.2

Formaty ramek – 802.2 (typ w 802.3) 3 bajty dla starego DIX
4 bajty dla SNA i NETBEUI 2 pierwsze bajty to SAP – aktualnie o treści: 0x0404 dla SNA 0xF0F0 dla NETBEUI

Formaty ramek – SNAP Kompromis dla starego DIX i możliwości zapisu typu ramki w nowym formacie 802.3 SAP to dwa bajty 0xAA Datagram to pole 0x03 Stare DIX mogą być prosto przekonwertowane na 802 SNAP przez przeniesienie pola DIX type o 8 bajtów „do tyłu”

TCP/IP Autorzy: Jadwiga Groele, Robert Groele
Podstawy Protokołu TCP/IP

Podstawowe pojęcia Protokołem w sieci komputerowej nazywamy zbiór zasad syntaktycznych i semantycznych sposobu komunikowania się jej elementów funkcjonalnych. Tylko dzięki nim urządzenia tworzące sieć mogą się porozumiewać. Model warstwowy, w którym każda warstwa posługuje się własnym protokołem znacznie upraszcza projektowanie niezwykle skomplikowanego procesu komunikacji sieciowej. Muszą jednak jasno zostać zdefiniowane zasady współpracy tych protokołów. Warstwowy model OSI stanowi przykład opisu takich zasad, będąc w istocie “protokołem komunikacji między protokołami”.

Model OSI

OSI a TCP/IP

TCP/IP I Protokół TCP/IP jest “programowym protokołem komunikacji sieciowej” (ang. software-based communications protocol used in networking). Termin TCP/IP oznacza znacznie więcej niż tylko prostą kombinację protokołów TCP (ang. Transmission Control Protocol) i IP (ang. Internet Protocol). Oznacza on rozbudowany zestaw oprogramowania udostępniającego różnorodne usługi sieciowe.

TCP/IP II Protokół TCP/IP udostępnia metody przesyłania informacji pomiędzy poszczególnymi maszynami w sieci, zapewniając wiarygodne przesyłanie danych, obsługując pojawiające się błędy czy generując związane z transmisją informacje dodatkowe. Protokół TCP/IP umożliwia rozpatrywanie zagadnień dotyczących komunikacji niezależnie od sprzętu sieciowego.

Adresy fizyczne Ethernet wykorzystuje adresy 48-bitowe. Każdy komputer przyłączony do sieci Ethernet dostaje unikatowy 48-bitowy numer nazywany adresem eternetowym przypisany w procesie produkcji interfejsom sieciowym. Ponieważ adres ten związany jest ze sprzętem sieciowym nazywamy go adresem sprzętowym lub adresem fizycznym. Przestrzeń adresowa i przydzielanie adresów poszczególnym producentom sprzętu są zarządzane przez IEEE, dzięki temu żadne dwie karty interfejsu nie mają takiego samego adresu eternetowego.

Ramka Ethernet Dane przesyłane przez sieć Ethernet są dzielone na ramki (ang. frame). Ramki Ethernetu mają zmienną długość - od 64 do 1518. Preambuła 8 oktetów Adres odbiorcy 6 oktetów Adres nadawcy 6 oktetów Typ ramki 2 oktety Dane ramki oktetów CRC 4 oktety

Pola ramki Ethernet I Preambuła Preambuła jest sekwencją 7 bajtową (56 bitów) z naprzemiennymi wartościami 1 i 0, stosowanymi dla synchronizacji. Służy przede wszystkim po to by dać czas komponentom sieci na wykrycie sygnału i odczytanie go, zanim nadejdzie ramka Ethernet z danymi. SFD (Start Frame Delimiter) SFD jest sekwencją 8 bitów w postaci , która wskazuje na początek ramki Ethernet z danymi.

Pola ramki Ethernet II DA MAC i SA MAC Pole adresu przeznaczenia DA MAC (Destination Address Medium Access Control) identyfikuje urządzenie lub wiele urzadzeń, które mają odebrać ramkę Ethernet. Pole adresu źródła SA MAC (Source Address MAC) identyfikuje urządzenie, które wysłało tą ramkę ethernet. Możemy wyróżnić trzy typy adresów MAC: unicastowy, czyli konkretny adres MAC pojedynczego urządzenia; multicastowy, czyli identyfikujący grupę urzadzeń; oraz broadcastowy, czyli taki, który ma wszystkie bity ustawione na "1", taką ramkę odbiorą wszystkie urzadzenia w sieci LAN.

Pola ramki Ethernet III
Dł/Typ Jeśli to pole ma wartość mniejszą lub równą 1500, to określa liczbę bajtów w polu Dane. Jeśli wartość jest większa niż 1536, wtedy pole określa naturę przesyłanego protokółu użytkownika. Dane Dane klienta MAC, pole to zawiera dane transmitowane od stacji źródłowej do stacji przeznaczenia. Maksymalna wielkość tego pola to 1500 bajtów, a gdy wartość tego pola spada poniżej 46 bajtów to wykorzystywane jest pole Dopełnienia (Dop.), by ramka Ethernet osiągnęła minimalną długość. Dop. Pole dopełnienia, wypełnione dodatkowymi bitami danych, stosowane tylko wtedy, gdy trzeba uzupełnić ramkę Ethernet do minimalnej długości 64 bajtów, licząć od pola DA MAC do FCS.

Pola ramki Ethernet IV FCS Pole FCS (Frame Check Sequence) zawiera 4 bajty cyklicznej kontroli nadmiarowej CRC (Cyclic Redundancy Check). Przed wysłaniem ramki MAC, stacja źródłowa dokonuje kalkulacji CRC z wszystkich bitów ramki Ethernet od pola DA MAC, aż do pola Dop. (czyli z wszystkich pól oprócz preambuły, SFD i FCS), następnie wpisuje ją do pola FCS. Gdy ramka zostanie odebrana przez stację przeznaczenia, wykonywana jest ponowna kalkulacja CRC i jeśli wartość przeliczenia nie jest identyczna z wartością w polu FCS odebranej ramki Ethernet, to uważa się taka ramkę za błędną i odrzuca.

Pola ramki VLAN I Tagowanie VLAN ( 802.1Q/802.1p) - Standard IEEE 802.3ac definiuje rozszerzenia ramki Ethernet w celu obsługi wirtualnych sieci lokalnych VLAN (Virtual LAN) w sieciach Ethernet. Sam protokół VLAN został określony w standardzie IEEE 802.1Q, a 802.3ac wprowadza szczegóły implementacji tego protokołu charakterystyczne dla Ethernet.

Pola ramki VLAN II Protokół VLAN umożliwia włożenie znacznika (tag 802.1Q) do ramki Ethernet by zidentyfikować wirtualny LAN (VLAN), do którego należy ta ramka. Dzięki temu tworzy się logiczne grupy, do których przydziela się ramki, co daje korzyści w postaci: łatwiejszego zarządzania siecią, zwiększenia bezpieczeństwa sieciowego, możliwością tworzenia grup roboczych, ograniczenia domen broadcastowych.

Pola ramki VLAN III Tag VLAN, który jest 4-bajtowy, jest wkładany pomiędzy pola SA MAC a Dł/Typ. Pierwsze 2 bajty tagu, TPID (Tag Protocol Identifier), określają "802.1QTagType", który ma zawsze wartość 0x8100. Informacja w tym polu wskazuje, że włożony jest tag VLAN i informuje, że oryginalne pole Dł/Typ można znaleźć w ramce Ethernet z przesunięciem 4-bajtowym. Kolejne 2 bajty tagu zawierają następujące informacje:

Pola ramki VLAN IV

Pola ramki VLAN V user_priority: 3 bity pozwalające na przydzielenie odpowiedniego poziomu priorytetu dla ramki Ethernet, to pole jest traktowane jako 802.1p; CFI: 1 bit Canonical Format Indicator wskazuje, czy jest obecne pole RIF (ROuting Information Field); VID: 12 bitów identyfikatora VLAN (VLAN ID), który jednoznacznie identyfikuje VLAN, do którego należy ramka Ethernet, to pole jest traktowane jako 802.1Q. UWAGA - dodanie tagu VLAN zwiększa maksymalną długość ramki Ethernet o 4 bajty, czyli do 1522 bajtów.

Adresy IP I Do rozróżniania komputerów TCP/IP używa 32 bitowej liczby całkowitej, nazywanej adresem IP. Pomysłowość tego systemu adresowania polega na tym, że umożliwia on efektywne wyznaczanie tras pakietów. Jest to możliwe dzięki temu, że adres IP zawiera informację o tym do jakiej sieci jest włączony dany komputer oraz jednoznaczny adres komputera w tej sieci. Adres IP jest używany przy wszystkich operacjach związanych z wymianą informacji z daną maszyną.

Adresy IP II

Adres IP III Obserwując najstarsze bity adresu możemy stwierdzić do jakiej klasy należy dany adres, w efekcie możemy stwierdzić ile bitów będzie adresowało sieć, ile zaś sam komputer. Zwróćmy uwagę, że aby określić przynależność do jednej z trzech zasadniczych klas (A, B, C) wystarczą dwa pierwsze bity. Adresów klasy A wykorzystywanych przez duże sieci jest niewiele (na adres sieci przeznaczone jest 7 bitów, więc sieci takich jest 27=127) ale w każdej z sieci tej klasy może być ponad 16 milionów komputerów (na adres maszyny przeznaczone jest 24 bity więc otrzymujemy 224 maszyn).

Adres IP IV Klasa B przeznaczona jest dla sieci średniej wielkości mających od 28 (tj. 256) do 216 maszyn - 14 bitów określa sieć, zaś 16 bitów komputer. W efekcie otrzymujemy sieci, które mogą mieć do komputerów każda. W klasie C sieć adresowana jest za pomocą 21 bitów - daje to 221 sieci (ponad 2 miliony) ale w każdej z nich może być co najwyżej 28=256 maszyn. Adres klasy D (ang. multicast address) ma specjalne znaczenie - jest używany w sytuacji gdy ma miejsce jednoczesna transmisja do większej liczby urządzeń.

Klasy – zakresy adresów IP
Klasa Najniższy adres Najwyższy adres A B C D E

Adres IP V Adres IP każdego urządzenia, które może być połączone z intersiecią musi być unikalny w skali światowej. W celu zapewnienia jednoznaczności identyfikatorów sieci, wszystkie adresy przydzielane są przez jedną organizację. Zajmuje się tym Internet Network Information Center (INTERNIC). Przydziela ona adresy sieci, zaś adresy maszyn w ramach sieci administrator może przydzielać bez potrzeby kontaktowania się z organizacją. Organizacja ta przydziela adresy tym instytucjom, które są lub będą przyłączone do ogólnoświatowej sieci INTERNET.

Protokół ARP I Przekształcenia adresu IP na adres fizyczny dokonuje protokół odwzorowania adresów ARP (ang. Address Resolution Protocol), który zapewnia dynamiczne odwzorowanie i nie wymaga przechowywania tablicy przekształcania adresowego. Wykorzystuje on możliwość rozgłaszania danych w sieci ethernet. W rozwiązaniu tym nowe maszyny mogą być łatwo dodawane, ponadto nie wymagane jest przechowywanie centralnej bazy danych.

Protokół ARP II

Protokół ARP III W celu zredukowania kosztów komunikacji, komputery używające protokołu ARP przechowują w pamięci podręcznej ostatnio uzyskane powiązania adresu IP z adresem fizycznym, w związku z tym nie muszą ciągle korzystać z protokołu ARP. Gdy tylko komputer otrzymuje odpowiedź ARP, zapamiętuje adres IP jego nadawcy i odpowiadający mu adres sprzętowy, aby móc później go wykorzystać. Przy przesyłaniu pakietu komputer zawsze, zanim wyśle prośbę ARP, zagląda do pamięci podręcznej czy nie ma tam odpowiedniego dowiązania, jeżeli takie znajduje, to nie musi nic rozgłaszać w sieci.

Protokół RARP I Komputery bez dysku twardego (lub inne sytuacje, gdy nie można zapisać adresu IP) ustalają swój adres IP maszyny uprawnionej do świadczenia takich usług, przy pomocy protokołu odwrotnego odwzorowania adresów RARP (ang. Reverse Address Resolution Protocol). Umożliwia on uzyskiwanie adresu IP na podstawie znajomości własnego adresu fizycznego (pobranego z interfejsu sieciowego).

Protokół RARP II Problem ten rozwiązuje się w sposób przypominający uzyskiwanie adresu fizycznego, tzn. “ściąga się” z serwera adres IP danej maszyny. Działanie bazuje na tym, że maszyna posiada swój adres fizyczny i może się nim posłużyć w obrębie jednej sieci. Komputer taki czasowo używa swojego adresu fizycznego zanim nie ustali swojego adresu IP. Wykorzystanie adresu fizycznego ma dwie zalety: Adres fizyczny jest pobierany z interfejsu sieciowego, jest zatem łatwo dostępny. Adres ten zależy od sieci, a nie od producenta lub typu procesora, a zatem wszystkie maszyny w danej sieci będą używały identyfikatorów o tym samym formacie.

Protokół RARP III

Usługi TCP/IP

Protokół Internetowy IP I
Najbardziej podstawowa usługa - przenoszenie pakietów bez użycia połączenia przy pomocy dostępnych możliwości nosi nazwę Internet Protocol, a zwykle oznacza się ją skrótem IP. Jest ona zdefiniowana jako zawodny (ang. unreliable) system przenoszenia pakietów bez użycia połączenia, tzn. nie ma gwarancji, że przenoszenie zakończy się sukcesem. Pakiet może zostać zagubiony, zduplikowany, zatrzymany lub dostarczony z błędem, a system nie sprawdzi, że coś takiego zaszło, a także nie powiadomi o tym ani nadawcy ani odbiorcy.

Protokół Internetowy IP II
IP to usługa bez użycia połączenia, gdyż każdy pakiet obsługiwany jest niezależnie od innych. Pakiety z jednego ciągu wysłane z danego komputera do drugiego mogą podróżować różnymi ścieżkami, niektóre z nich mogą zostać zagubione, natomiast inne dojdą bez przeszkód. IP wykorzystuje przenoszenie “przy użyciu dostępnych możliwości”, gdyż oprogramowanie czyni co może, aby dostarczyć pakiety. Oznacza to, że pakiety nie są tracone bez przyczyny - niepewność w dostarczaniu pojawia się w wyniku wyczerpania zasobów albo błędów sieci bazowych.

Protokół Internetowy IP III
Protokół IP zawiera trzy ważne definicje: Definicję podstawowej jednostki przesyłanych danych, używanej w sieciach TCP/IP. Określa ona dokładny format wszystkich danych przesyłanych przez sieć. Definicję operacji trasowania, wykonywanej przez oprogramowanie IP, polegającej na wybieraniu trasy, którą będą przesyłane dane. Zawiera zbiór reguł, które służą do realizacji zawodnego przenoszenia pakietów. Reguły te opisują, w jaki sposób węzły i routery powinny przetwarzać pakiety, jak i kiedy powinny być generowane komunikaty o błędach oraz kiedy pakiety mogą być porzucane.

Datagram IP I Podstawowa jednostka przesyłanych danych nazywana jest datagramem. Datagram podzielony jest na nagłówek i dane. Nagłówek datagramu zawiera adres nadawcy i odbiorcy oraz pole typu, które identyfikuje zawartość datagramu.

Datagram IP II Datagram przypomina ramkę sieci fizycznej. Różnica polega na tym, że nagłówek ramki zawiera adresy fizyczne, zaś nagłówek datagramu adresy IP (omówione wcześniej).

Format Datagramu IP I

Format Datagramu IP II Pole WERSJA (4-bitowe) - zawiera informację o wersji protokołu IP, która była używana przy tworzeniu datagramu. Informacja ta jest wykorzystywana do sprawdzania, czy nadawca, odbiorca i wszystkie routery zgadzają się na format datagramu. Oprogramowanie IP zawsze sprawdza pole wersji w celu upewnienia się, czy jego format zgadza się ze spodziewanym. Obecna wersja protokołu IP to 4. Pole DŁUGOŚĆ NAGŁÓWKA (4-bitowe) - zawiera informację o długości nagłówka mierzoną w 32-bitowych słowach.

Format Datagramu IP III
Pola OPCJE IP i UZUPEŁNIENIE najczęściej nie są wypełnione. Ponieważ długość pozostałych pól nagłówka jest stała, więc nagłówek najczęściej ma długość równą 5 (słów 32-bitowych). Pole DŁUGOŚĆ CAŁKOWITA (16-bitowe) zawiera, mierzoną w bajtach, długość całego datagramu IP. Rozmiar pola danych można uzyskać przez odjęcie DŁUGOŚCI NAGŁÓWKA od DŁUGOŚCI CAŁKOWITEJ. Ponieważ pole DŁUGOŚĆ CAŁKOWITA ma 16 bitów długości, maksymalny możliwy rozmiar datagramu IP wynosi czyli bajtów.

Format Datagramu IP Typ obsługi I
Pole TYP OBSŁUGI (8-bitowe) określa sposób w jaki powinien być obsłużony datagram. Składa się ono z pięciu podpól.

Format Datagramu IP Typ obsługi II
Podpole PIERWSZEŃSTWO (3-bitowe) zawiera informację o stopniu ważności datagramu, od 0 (normalny stopień ważności) do 7 (sterowanie siecią). Umożliwia to nadawcy wskazanie jak ważny jest dany datagram. Bity O, S, P określają rodzaj przesyłania, którego wymaga datagram. Ustawienie bitu O - oznacza prośbę o krótkie czasy oczekiwania, S - o przesyłanie szybkimi łączami, P - o dużą pewność przesyłanych danych.

Format Datagramu IP Typ obsługi III
Ponieważ nie ma pewności, że trasa o wskazanych parametrach będzie dostępna, informacje te należy traktować tylko jako podpowiedź dla algorytmów trasowania; jednocześnie wskazanie wszystkich trzech sposobów obsługi na raz, zwykle nie ma sensu. W praktyce większość oprogramowania węzłów i routerów ignoruje pole typ obsługi.

Enkapsulacja I (kapsułkowanie)

Enkapsulacja II (kapsułkowanie)
Ramki sieci fizycznych muszą być rozpoznawane przez sprzęt, natomiast datagramy są obsługiwane przez oprogramowanie. Mogą zatem mieć dowolną długość wybraną przez projektanta. Widzieliśmy już, że w obecnym formacie datagramu pole długości całkowitej może mieć najwyżej 16 bitów, co ogranicza datagram do bajtów. Ograniczenie to może zostać jednak zmienione w następnych wersjach protokołu.

Enkapsulacja III (kapsułkowanie)
W praktyce pojawiają się bardziej znaczące ograniczenia na rozmiar datagramu. Aby datagram mógł przemieścić się od jednej maszyny do drugiej musi być przeniesiony przez bazową sieć fizyczną. Aby transport ten był efektywny, należałoby zagwarantować, żeby każdy datagram przenoszony był w oddzielnej fizycznej ramce.

Enkapsulacja IV (kapsułkowanie)
Rozwiązanie, w którym jeden datagram przenoszony jest przez jedną ramkę sieciową jest nazywane kapsułkowaniem (ang. encapsulation). Datagram zachowuje się wówczas jak każdy inny komunikat przesyłany z jednej maszyny do drugiej. Sprzęt nie rozpoznaje formatu datagramu ani nie rozumie adresu docelowego IP. Dlatego gdy jedna maszyna przesyła datagram IP do drugiej, cały datagram podróżuje w części ramki sieciowej przeznaczonej na dane.

Fragmentacja I Datagram może przemieszczać się przez różne sieci fizyczne. Każda z nich ma ustaloną górną granicę ilości danych, które mogą być przesłane w jednej ramce. Np. w sieci Ethernet “porcja” danych jest ograniczona do 1500 bajtów, natomiast w sieci FDDI można przesłać ok bajtów w jednej ramce. Ten parametr sieci nosi nazwę maksymalnej jednostki transmisyjnej danej sieci -MTU (ang. Maximum Transfer Unit).

Fragmentacja II Wielkość MTU może być całkiem mała, np. niektóre rodzaje sprzętu ograniczają porcje danych do 128 i mniej bajtów. Ograniczenie wielkości datagramów, tak aby pasowały do najmniejszego MTU, byłoby nieefektywne w przypadku przechodzenia przez sieci, które mogą przenosić większe ramki. Jednak zezwolenie, aby datagramy były większe niż minimalne sieciowe MTU sprawia, że datagram może nie zawsze zmieścić się w pojedynczej ramce sieciowej.

Fragmentacja III Wobec tego zamiast projektować datagramy, które spełniają ograniczenia sieci fizycznych, oprogramowanie TCP/IP dobiera wygodny początkowy rozmiar datagramu i oferuje sposób dzielenia datagramu na mniejsze części, kiedy datagram musi przejść przez sieć, która ma małe MTU. Mniejsze kawałki, na które jest dzielony datagram nazywane są fragmentami, a proces ten nazywa się fragmentacją. Gdy takie pofragmentowane datagramy dotrą do odbiorcy podlegają procesowi odwrotnemu czyli defragmentacji.

Fragmentacja IV Protokół IP nie ogranicza rozmiaru datagramów ani nie gwarantuje, że duże datagramy zostaną dostarczone bez fragmentacji. Nadawca może wybrać dowolny rozmiar datagramu, jaki uważa za stosowny - fragmentacja i składanie dokonują się automatycznie, nadawca nie musi wykonywać tutaj żadnych specjalnych czynności.

Fragmentacja V

Fragmentacja VI Fragmentowanie datagramu oznacza dzielenie go na wiele części. Każda z tych części ma format pierwotnego datagramu. Poniższy rysunek przedstawia wynik fragmentacji. Każdy z fragmentów zawiera nagłówek, w którym jest powielona większość zawartości nagłówka pierwotnego datagramu (nie licząc bitu w polu ZNACZNIKI, który wskazuje, że jest to fragment), a za którym jest tyle danych, ile może być przeniesione we fragmencie, tak aby długość całkowita nie przekroczyła MTU sieci, przez którą musi on przejść.

Fragmentacja VII

Fragmentacja VIII W intersieci TCP/IP od chwili, gdy datagram jest dzielony na fragmenty, fragmenty te podróżują jako oddzielne datagramy, aż do ostatecznego odbiorcy, gdzie muszą zostać złożone. Rozwiązanie to ma dwie wady. Ponieważ datagramy nie są składane natychmiast po przedostaniu się przez sieć o małym MTU, małe fragmenty muszą być przenoszone od miejsca fragmentacji aż do końcowego odbiorcy, nawet jeżeli niektóre sieci fizyczne napotykane za miejscem fragmentacji mają duże MTU.

Fragmentacja IX Po drugie, gdy jakiś fragment zostanie zagubiony, datagram nie może zostać odtworzony. Maszyna odbierająca, gdy otrzymuje fragment początkowy, uruchamia zegar składania. Gdy czas na zegarze przekroczy określoną wartość, zanim przybędą wszystkie fragmenty, maszyna odbierająca porzuca otrzymane fragmenty bez przetwarzania datagramu. Stąd prawdopodobieństwo utraty datagramu wzrasta, gdy pojawia się fragmentacja, gdyż utrata pojedynczego fragmentu powoduje utratę całego datagramu.

Kontrola Fragmentacji I
Nagłówek datagramu - trzy pola nagłówka IDENTYFIKACJA, ZNACZNIKI, PRZESUNIĘCIE FRAGMENTU służą kontroli procesów fragmentacji i składania datagramów: Pole IDENTYFIKACJA (16-bitowe) zawiera liczbę całkowitą jednoznacznie identyfikującą datagram. Identyfikator jest niezbędny, gdyż zapobiega wymieszaniu się fragmentów pochodzących od różnych datagramów - wszystkie kawałki będące częściami tego samego datagramu posiadają ten sam identyfikator.

Kontrola Fragmentacji II
Pole ZNACZNIKI (3-bitowe) służy do kontroli fragmentacji. Pierwszy z trzech bitów jest nie używany, nadanie drugiemu wartości 1 oznacza bezwzględny zakaz fragmentacji. Jeśli datagram nie może być przesłany w całości, zostaje odrzucony i sygnalizowany jest błąd. Ostatni z bitów ZNACZNIKÓW umożliwia identyfikację ostatniego kawałka datagramu - ma w nim wartość 0, w pozostałych przypadkach 1.

Kontrola Fragmentacji III
Pole PRZESUNIĘCIE FRAGMENTU (13-bitowe) zawiera informację w którym miejscu datagramu umiejscowione są informacje przesyłane w tym kawałku. Jest ono mierzone w jednostkach 64-bajtowych. Umożliwia to poprawne scalenie datagramu - nie istnieje nic w rodzaju kolejnego numeru kawałka w datagramie.

Kontrola Fragmentacji IV
Pole CZAS ŻYCIA TTL (ang. Time To Live) określa jak długo, w sekundach, datagram może pozostawać w systemie sieci. Ten limit czasowy wynosi zwykle od 15 do 30 sekund. Wymogiem protokołu TCP/IP jest aby każdy router podczas przetwarzania nagłówka datagramu zmniejszał wartość pola CZAS ŻYCIA co najmniej o 1, nawet jeśli rzeczywiste przetwarzanie trwało krócej. Jeśli jednak router jest przeciążony i czas przetwarzania jest dłuższy wówczas wartość pola CZAS ŻYCIA zmniejsza się o czas faktycznego pozostawania datagramu wewnątrz routera. Gdy wartość pola maleje do zera router porzuca datagram i wysyła do nadawcy komunikat o błędzie. Mechanizm ten zapobiega podróżowaniu datagramów w sieci w nieskończoność, np. gdy tablice tras są nieaktualne, a routery wyznaczają datagramom trasy w kółko.

Kontrola Fragmentacji V
Pole PROTOKÓŁ zawiera numer identyfikacyjny protokołu transportowego dla którego pakiet jest przeznaczony. W rzeczywistości zawartość pola PROTOKÓŁ wyznacza format pola DANE. Numery poszczególnych protokołów transportowych określone są przez Internet Network Information Center (INTERNIC). Najbardziej popularnymi są: ICMP oznaczony numerem 1 oraz TCP oznaczony numerem 6. Pełna lista protokołów obejmuje ok. 50 pozycji i jest dostępna w kilku dokumentach RFC.

Kontrola Fragmentacji VI
Pole SUMA KONTROLNA NAGŁÓWKA służy do sprawdzenia sensowności zawartości nagłówka. Obejmuje tylko nagłówek IP i nie dotyczy w żadnym stopniu danych. Zawiera bitową negację sumy obliczonej jako suma kolejnych 16-bitowych półsłów nagłówka. Obliczenie sumy kontrolnej bezpośrednio po otrzymaniu pakietu oraz porównanie jej z wartością zapisaną w niniejszym polu pozwala wykryć większość przekłamań, lecz nie wszystkie: np. nie jest wykrywane zagubienie zerowego półsłowa. Ponieważ jednak sumy kontrolne protokołów TCP i UDP obejmują cały pakiet więc przemycenie tego typu błędu jest praktycznie niemożliwe.

Kontrola Fragmentacji VII
Pola ADRES IP NADAWCY i ADRES IP ODBIORCY zawierają 32-bitowe adresy IP pierwotnego nadawcy i końcowego odbiorcy. (Z wyjątkiem sytuacji gdy datagram zawiera opcje wyznaczania trasy przez nadawcę). Pole OPCJE IP ma zmienną długość. Pole UZUPEŁNIENIE zależy od wybranych opcji. Zawiera ono zerowe bity, które mogą być potrzebne do zapewnienia, że nagłówek ma długość, która jest wielokrotnością 32 bitów (ponieważ pole DŁUGOŚĆ NAGŁÓWKA zawiera wartość mierzoną w jednostkach 32-bitowych).

Kontrola Fragmentacji VIII
Pole OPCJE IP nie występuje w każdym datagramie - pierwotnym zastosowaniem opcji było ułatwienie testowania i usuwania błędów. Długość pola OPCJE zmienia się w zależności od tego jakie opcje są wybrane. Niektóre z nich mają długość 1 bajta, inne mają długość zmienną. Każda opcja składa się kodu opcji długości 1 bajta po którym może się pojawić ciąg bajtów tej opcji.

Kontrola Fragmentacji X
Pole OPCJE składa się z trzech części. 1-bitowy znacznik kopiuj określa, że opcje maja być przekopiowane do wszystkich fragmentów (wartość 1), bądź tylko do pierwszego (wartość 0).

Kontrola Fragmentacji XI
Bity KLASA OPCJI określają ogólną klasę opcji: Klasa opcji Znaczenie 0 Kontrola datagramów lub sieci 1 Zarezerwowane do przyszłego użytku 2 Poprawianie błędów i pomiary 3 Zarezerwowane do przyszłego użytku Opcje, które mogą towarzyszyć datagramom IP - podano wartości KLASY OPCJI oraz NUMERU OPCJI. (większość opcji jest używana do celów kontrolnych):

Kontrola Fragmentacji XII
Klasa opcji Numer opcji Długość Opis Koniec listy opcji. Używana gdy opcje nie kończą się wraz z końcem nagłówka. Bez przypisanej funkcji - wypełnienie Tajność - używana do zastosowań wojskowych 0 3 zmienna Swobodne trasowanie wg nadawcy - używana do prowadzenia datagramu określoną ścieżką. 0 7 zmienna Zapisuj trasę - używana do śledzenia trasy. 0 9 zmienna Rygorystyczne trasowanie wg nadawcy - używana do ścisłego prowadzenia datagramu. 2 4 zmienna Intersieciowy datownik - używana do zapisywania czasów wzdłuż ścieżki.

Kontrola Fragmentacji XIII
Aby przedstawić koleje życia datagramu należy wyjaśnić pojęcie routera i trasowania (ang. routing). W systemie z wymianą pakietów trasowanie oznacza proces wyboru ścieżki, po której będą przesyłane pakiety, a router to komputer, który dokonuje tego wyboru. Algorytm wyznaczania tras musi uwzględniać sposób przesyłania pakietu przez wiele sieci fizycznych.

Kontrola Fragmentacji XIV
Upraszczając zagadnienie można wyróżnić dwa rodzaje trasowania: dostarczanie bezpośrednie i pośrednie. Dostarczanie bezpośrednie - przesyłanie danych od jednej maszyny do drugiej w ramach pojedynczej sieci fizycznej - jest podstawą komunikacji. Dwie maszyny mogą wziąć udział w bezpośrednim przesyłaniu tylko wtedy, kiedy są podłączone do tej samej sieci fizycznej (np. Ethernet). Dostarczanie pośrednie ma miejsce, gdy adresat nie jest podłączony do tej samej sieci fizycznej, co wymaga przesłania datagramu za pośrednictwem routera.

Życie datagramu I Gdy aplikacja ma zamiar wysłać datagram w sieć, wykonuje kilka prostych kroków. Najpierw konstruuje datagram zgodnie z wymogami lokalnej implementacji IP. Zostaje obliczona suma kontrolna dla danych i skonstruowany nagłówek IP. Następnie pierwszy węzeł na drodze wędrówki datagramu określić musi etap następny - inną maszynę w sieci lub router, gdy dane muszą się z sieci wydostać. Jeżeli dane są szczególnie cenne, w nagłówku IP zostaną ustawione odpowiednie opcje. Na koniec datagram jest “posyłany w sieć”.

Życie datagramu II Każdy router otrzymujący datagram wykonuje na nim serię testów. Gdy warstwa sieciowa zdejmie z niego swój nagłówek, warstwa IP weryfikuje sumę kontrolną datagramu. W razie niezgodności datagram jest odrzucany i do węzła-nadawcy kierowany jest komunikat o błędzie. Następnie pole TTL jest odpowiednio zmniejszone i sprawdzane. Jeśli limit czasu jest przekroczony sygnalizowany jest błąd. Po określeniu następnego węzła (na podstawie adresu docelowego) zostaje zapisana nowa wartość TTL i nowa suma kontrolna.

Życie datagramu III Jeżeli konieczna jest fragmentacja, jest on dzielony na mniejsze datagramy i każdy z nich opatrywany jest nagłówkiem IP. W końcu datagram przekazywany jest z powrotem do warstwy sieciowej.

Życie datagramu VI Węzeł końcowy dokonuje na datagramie:
Weryfikacji sumy kontrolnej i jeśli jest poprawna sprawdza, czy istnieją jeszcze inne fragmenty datagramu, czy też dotarł on w jednym kawałku. W przypadku fragmentacji węzeł otrzymując kolejne fragmenty dokonuje scalania (musi się oczywiście zmieścić w założonym limicie czasu). W końcu zdejmowany jest z datagramu nagłówek IP, odtworzony jest oryginalny komunikat i przesyłany w stronę wyższych warstw. Gdy wymagana jest odpowiedź, zostaje ona wygenerowana i przesłana drogą powrotną.

ICMP I Oprogramowanie Internet Protocol realizuje zawodne przenoszenie pakietów bez użycia połączenia za pomocą przekazywania datagramów w routerach. Datagram wędruje od nadawcy przez różne sieci i routery aż do końcowego odbiorcy. Jeżeli router nie potrafi ani wyznaczyć trasy ani dostarczyć datagramu, albo gdy wykrywa sytuację mającą wpływ na możliwość dostarczenia datagramu (np. przeciążenie sieci, wyłączenie maszyny docelowej, wyczerpanie się licznika czasu życia datagramu) to musi poinformować pierwotnego nadawcę, aby podjął działania w celu uniknięcia skutków tej sytuacji.

ICMP II Protokół komunikatów kontrolnych internetu ICMP (ang. Internet Control Message Protocol) powstał aby umożliwić routerom oznajmianie o błędach oraz udostępnianie informacji o niespodziewanych sytuacjach. Protokół ICMP jest traktowany jako wymagana część IP i musi być realizowany przez każdą implementację IP. Chociaż protokół ICMP powstał, aby umożliwić routerom wysyłanie komunikatów to każda maszyna może wysyłać komunikaty ICMP do dowolnej innej.

ICMP III Podobnie jak ruch innego rodzaju komunikaty ICMP podróżują w intersieci w części w częściach datagramów IP przeznaczonych na dane. Jednak odbiorcą końcowym komunikat ICMP nie jest ani program użytkowy, ani użytkownik, ale oprogramowanie IP na tej maszynie. Przychodzący komunikat błędu ICMP jest obsługiwany przez moduł oprogramowania ICMP. Oczywiście gdy ICMP zorientuje się, że problem spowodował dany protokół wyższego rzędu lub program użytkowy, przekaże informacje do odpowiedniego modułu.

ICMP IV Z technicznego punktu widzenia ICMP jest mechanizmem powiadamiania o błędach. Udostępnia on routerom, które rozpoznają błąd, sposób powiadomienia o nim nadawcy, którego błąd dotyczy. Chociaż w specyfikacji protokołu są określone zamierzone sposoby korzystania z ICMP i sugestie na temat tych działań, które mogą być podejmowane w odpowiedzi na komunikaty o błędach, ICMP nie dla każdego możliwego błędu wyszczególnia działania, jakie mają być zapoczątkowane.

ICMP V Gdy datagram powoduje błąd, ICMP może jedynie powiadomić pierwotnego nadawcę o przyczynie. Nadawca musi otrzymaną informację przekazać danemu programowi użytkownika, albo podjąć inne działanie mające na celu uporanie się z tym problemem.

ICMP VI Każdy komunikat ICMP ma własny format, ale wszystkie zaczynają się trzema takimi samymi polami: 8-bitowe pole TYP komunikatu identyfikuje komunikat, 8-bitowe pole KOD daje dalsze informacje na temat rodzaju komunikatu, Pole SUMA KONTROLNA (obliczane podobnie jak suma IP, ale suma kontrolna ICMP odnosi się tylko do komunikatu ICMP). Ważne jest, że chociaż komunikaty ICMP są kapsułkowane i przenoszone przy użyciu IP, nie są protokołem wyższego rzędu lecz wymaganą częścią IP.

ICMP VII Oprócz tego komunikaty ICMP oznajmiające o błędach zawsze zawierają nagłówek i pierwsze 64 bity danych datagramu z którym były problemy.

ICMP VIII Aby komunikaty ICMP mogły zostać dostarczone wymagają dwóch poziomów kapsułkowania. Każdy komunikat ICMP podróżuje przez intersieć w części datagramu IP przeznaczonej na dane, a ten jak wiemy przemieszcza się przez sieć fizyczną w części dla danych ramki.

ICMP IX Trasy datagramów przenoszących komunikaty ICMP są wyznaczane dokładnie tak, jak dla datagramów przenoszących informacje użytkowników - nie mają one żadnych dodatkowych priorytetów czy zabezpieczeń. W efekcie i same komunikaty o błędach mogą zostać zagubione albo zniszczone. Co więcej w przeciążonej sieci komunikat o błędzie może spowodować dodatkowe przeciążenie. Zrobiono więc wyjątek w procedurach obsługi błędów: komunikaty o błędach nie są tworzone w przypadku gdy błąd został spowodowany przez datagram IP niosący komunikat ICMP.

Adresowanie Ostatecznego Adresata I
Adresowanie wprost do konkretnego procesu z wielu powodów nie byłoby dobrym rozwiązaniem z kilku powodów: Ponieważ procesy tworzone i likwidowane są dynamicznie, Nadawca ma zbyt mało informacji aby wskazać proces na innej maszynie, Przeładowanie systemu operacyjnego powoduje zmianę wszystkich procesów itp. Wreszcie chcielibyśmy mieć możliwość określania odbiorców na podstawie realizowanych przez nich funkcji, nie wiedząc, który proces realizuje te funkcje, ponadto w systemach umożliwiających pojedynczym procesom obsługę więcej niż jednej funkcji odbiorca musi koniecznie mieć możliwość ustalenia, jakiej funkcji życzy sobie nadawca.

Adresowanie Ostatecznego Adresata II
Zamiast więc procesów jako ostatecznych odbiorców komunikatów wprowadzony został zbiór abstrakcyjnych punktów docelowych zwanych portami protokołów. Każdy port jest identyfikowany za pomocą dodatniej liczby całkowitej. Lokalny system operacyjny zapewnia mechanizm interfejsu, który pozwala procesom na określenie portu i dostępu do niego.

Adresowanie Ostatecznego Adresata III
W celu połączenia się z odległym portem nadawca musi znać adres IP maszyny docelowej, jak i numer docelowego portu protokołu na tej maszynie. Każdy komunikat musi zawierać numer portu odbiorcy na maszynie, do której został wysłany, oraz numer portu nadawcy na maszynie, do której mają być adresowane odpowiedzi. dzięki temu dowolny proces odbierający komunikat może wysłać odpowiedź do nadawcy.

UDP I W zestawie protokołów TCP/IP protokół datagramów użytkownika UDP (ang. User Datagram Protocol), zapewnia porty protokołów używane do rozróżniania poszczególnych programów wykonywanych na pojedynczej maszynie. Oprócz wysyłanych danych, każdy komunikat UDP zawiera numer portu odbiorcy i numer portu nadawcy, dzięki czemu oprogramowanie UDP odbiorcy może dostarczyć komunikat do właściwego adresata oraz umożliwia wysłanie odpowiedzi.

UDP II Do przesyłania komunikatów między maszynami UDP używa podstawowego protokołu IP i ma tę samą niepewną, bezpołączeniową semantykę dostarczania datagramów co IP - nie używa potwierdzeń w celu upewnienia się, o dotarciu komunikatów, nie porządkuje przychodzących komunikatów i nie zapewnia mechanizmu kontroli szybkości przesyłania danych między maszynami. Z tego powodu komunikaty UDP mogą być gubione, duplikowane lub przychodzić w innej kolejności niż były wysłane, ponadto pakiety mogą przychodzić szybciej niż odbiorca może je przetworzyć.

UDP III Program użytkowy korzystający z UDP musi na siebie wziąć odpowiedzialność za rozwiązanie problemów niezawodności, w szczególności za gubienie komunikatów, ich duplikowanie, opóźnienia, dostarczenie w niewłaściwej kolejności i utratę łączności z adresatem. Ponieważ sieci lokalne dają dużą niezawodność i małe opóźnienia wiele programów opartych na UDP dobrze pracuje w sieciach lokalnych, ale może zawodzić w większych intersieciach TCP/IP.

Format komunikatów UDP I
Każdy komunikat UDP nazywa się datagramem użytkownika. Datagram taki można podzielić na dwie części: nagłówek UDP i obszar danych UDP. Nagłówek datagramu użytkownika składa się z czterech 16-bitowych pól.

Format komunikatów UDP II

Format komunikatów UDP III
Pola PORT NADAWCY i PORT ODBIORCY zawierają 16-bitowe numery portów UDP używane do odnajdywania procesów oczekujących na dany datagram. Pole PORT NADAWCY jest opcjonalne. Pole DŁUGOŚĆ zawiera wartość odpowiadającą liczbie bajtów datagramu UDP wliczając nagłówek i dane. Minimalna więc wartość tego pola wynosi więc 8, czyli jest długością samego nagłówka. Pole SUMA KONTROLNA jest opcjonalne. Ponieważ jednak IP nie wylicza sum kontrolnych dla danych, suma kontrolna UDP jest jedyną gwarancją, że dane nie zostały uszkodzone.

Kapsułkowanie UDP I UDP jest pierwszym omówionym przez nas przykładem protokołu transportowego. W modelu warstw protokół UDP znajduje się powyżej warstwy protokołu intersieci. Umieszczenie datagramu UDP powyżej warstwy IP oznacza, że przed wysłaniem kompletny komunikat UDP wraz z nagłówkiem UDP i danymi jest w znany nam już sposób kapsułkowany w datagram IP. Tak więc warstwa IP jest odpowiedzialna wyłącznie za przesłanie danych między parą komputerów, zaś protokół UDP określa porty nadawcy i odbiorcy w obrębie jednej maszyny.

Kapsułkowanie UDP II

Kapsułkowanie UDP III U odbiorcy pakiet dociera do najniższej warstwy oprogramowania sieciowego i wędruje ku coraz wyższym warstwom. Każda warstwa usuwa jeden nagłówek przed przekazaniem komunikatu dalej, w efekcie przed przekazaniem komunikatu przez ostatnią warstwę oczekującemu procesowi zostają usunięte wszystkie nagłówki. Datagram UDP otrzymany od IP na maszynie docelowej jest identyczny z tym który UDP przekazało do IP na maszynie źródłowej, co więcej dane przekazywane przez UDP procesowi użytkownika na maszynie docelowej są dokładnie takie, jakie użytkownik przekazał do UDP na maszynie źródłowej.

Multipleksowanie i demultipleksowanie I
Protokoły komunikacyjne wykorzystują metody multipleksowania i demultipleksowania na poziomach wszystkich warstw. Przy wysyłaniu komputer nadawcy dołącza do danych dodatkowe bity, które wskazują typ komunikatu, program, który go nadał oraz używane protokoły. Wszystkie komunikaty są umieszczane w przeznaczonych do przesyłania ramkach sieciowych i łączone w strumień pakietów. U odbiorcy zaś te informacje są używane do sterowania przetwarzaniem.

Multipleksowanie i demultipleksowanie II

Multipleksowanie i demultipleksowanie III
Interfejs sieciowy demultipleksuje przychodzącą ramkę. W celu umożliwienia takiego wyboru, oprogramowanie nadawcy musi przed transmisją ustawiać pole typu ramki. Stąd każdy moduł oprogramowania, który wysyła ramki, używa pola typu do opisania zawartości ramki.

Multipleksowanie i demultipleksowanie IV
Gdy interfejs sieciowy zdemultipleksuje ramki i prześle te z nich, które zawierają datagramy IP do modułu IP, oprogramowanie IP wydobędzie z nich datagramy i dalej je zdemultipleksuje zgodnie z protokołem transportu. Aby zdecydować w jaki sposób obsłużyć datagram, oprogramowanie intersieci sprawdza nagłówek datagramu i wybiera na podstawie typu datagramu odpowiednie procedury (np. typy datagramów to: ICMP, UDP, TCP oraz EGP).

Multipleksowanie i demultipleksowanie V
Przy przetwarzaniu danych wejściowych UDP przyjmuje datagramy nadchodzące od oprogramowania IP i demultipleksuje je w zależności od portu UDP odbiorcy.

Multipleksowanie i demultipleksowanie VI
Teoretycznie wszelkie multipleksowanie i demultipleksowanie między oprogramowaniem UDP i programami użytkowymi jest realizowane przez mechanizm portów. W praktyce każdy program użytkowy musi uzyskać od systemu operacyjnego port protokołu i odpowiadający mu numer portu, zanim będzie mógł wysłać datagram UDP. Po przydzieleniu portu każdy datagram, który jest wysyłany przez program użytkowy przez ten port, będzie miał odpowiedni numer portu w polu PORT NADAWCY UDP.

Multipleksowanie i demultipleksowanie VII
Porty UDP można utożsamiać z kolejkami. W większości implementacji, gdy program użytkowy żąda od systemu przydzielenia określonego portu, system tworzy wewnętrzną kolejkę nadchodzących komunikatów. UDP, otrzymując datagram, sprawdza, czy numer portu odbiorcy odpowiada jednemu z obecnie używanych portów. Jeśli nie, wysyła komunikat ICMP “port niedostępny” i porzuca datagram. Jeśli któryś z portów pasuje, to UDP umieszcza nowy datagram w kolejce portu, skąd program użytkowy może go pobrać.

Multipleksowanie i demultipleksowanie VIII
Skąd komputer nadawca ma wiedzieć jakich numerów portu używa komputer odbiorca? Istnieją dwa różne podejścia do problemu przydzielania numerów portów. Jedno z nich opiera się na centralnym autorytecie. Każdy zgadza się na przydzielenie numerów portów, według potrzeb, przez władzę centralną, która publikuje listy przydzielonych numerów. Następnie wszelkie oprogramowanie używa numerów określonych na takiej liście. To podejście jest nazywane powszechnym przyporządkowaniem, a przydział portów określony przez władzę centralną - powszechnie znanym przydziałem portów.

Multipleksowanie i demultipleksowanie IX
Drugie podejście do zagadnienia przydzielania portów wykorzystuje wiązania dynamiczne. W tym przypadku numery portów nie są znane globalnie. Gdy program potrzebuje portu, zostaje on przydzielony przez oprogramowanie sieciowe. Aby ustalić bieżący przydział portów na tym komputerze, trzeba wysłać zapytanie, którego portu używa interesująca nas usługa.

Multipleksowanie i demultipleksowanie X
Projektanci TCP/IP wybrali rozwiązanie pośrednie, w którym niektóre numery portów są przydzielane centralnie, lecz wiele numerów jest dostępnych dla programów użytkowych. Przydzielone numery portów zaczynają się od małych wartości i rosną, duże wartości są wykorzystywane do przydzielania dynamicznego.

TCP I Protokół kontroli transmisji (ang. Transmission Control Protocol, TCP) - przesyłanie niezawodnymi strumieniami, wiarygodne dostarczenie datagramu. Protokół TCP będąc drugą najważniejszą usługą w sieci, wraz z IP dał nazwę całej rodzinie protokołów TCP/IP. Pomimo związku z protokołem IP - TCP jest protokołem w pełni niezależnym i może zostać zaadaptowany do wykorzystania z innymi systemami dostarczania. Możliwe jest używanie go zarówno w pojedynczej sieci takiej jak Ethernet jak i w skomplikowanej intersieci.

TCP II TCP organizuje dwukierunkową współpracę między warstwą IP, a warstwami wyższymi, uwzględniając przy tym wszystkie aspekty priorytetów i bezpieczeństwa. Musi prawidłowo obsłużyć niespodziewane zakończenie aplikacji, do której właśnie wędruje datagram, musi również bezpiecznie izolować warstwy wyższe - w szczególności aplikacje użytkownika - od skutków awarii w warstwie protokołu IP. Scentralizowanie wszystkich tych aspektów w jednej warstwie umożliwia znaczną oszczędność nakładów na projektowanie oprogramowania.

TCP III TCP rezyduje w modelu warstwowym powyżej warstwy IP. Warstwa ta jest jednak obecna tylko w tych węzłach sieci, w których odbywa się rzeczywiste przetwarzanie datagramów przez aplikacje, tak więc nie posiadają warstwy TCP na przykład routery, gdyż warstwy powyżej IP nie miałyby tam nic do roboty. Interfejs między programami użytkowymi a usługami niezawodnego dostarczania TCP/IP można scharakteryzować za pomocą następujących własności (patrz poniżej):

Własności TCP I Przesyłanie strumieniami. Gdy dwa programy użytkowe (procesy użytkownika) przesyłają duże ilości danych, myślimy o tych danych jako o strumieniu bitów, który jest podzielony na 8-bitowe oktety nieformalnie nazywane bajtami. Usługa dostarczania strumieniami na maszynie docelowej to przekazanie odbiorcy dokładnie tego samego ciągu oktetów, który na swojej maszynie przekazał nadawca.

Własności TCP IIa Łączenie w obwód wirtualny. Przed rozpoczęciem przesyłania, programy użytkowe zarówno nadawcy, jak i odbiorcy muszą się porozumieć z własnymi systemami operacyjnymi, informując je o potrzebie przesyłania za pomocą strumienia. Moduły oprogramowania protokołów w obu systemach porozumiewają się, wysyłając przez intersieć odpowiednie komunikaty sprawdzające czy transfer został autoryzowany oraz czy obydwie strony znajdują się w stanie gotowości. Po ustaleniu tych szczegółów moduły protokołów informują programy użytkowe, że połączenie zostało ustanowione i że można rozpocząć przesyłanie.

Własności TCP IIb W trakcie komunikacji oprogramowanie protokołów w dalszym ciągu wymienia informacje, które potwierdzają poprawność otrzymywanych danych. Jakiekolwiek zakłócenie komunikacji (np. z powodu awarii osprzętu sieciowego na ścieżce pomiędzy nadawcą a odbiorcą) zostaje wykryte przez obie maszyny i powoduje poinformowanie odpowiednich programów użytkowych. Tego typu połączenie określa się mianem obwodu wirtualnego, bo chociaż programy użytkowe widzą to połączenie tak, jakby istniał tutaj specjalny obwód elektroniczny, to niezawodność jest złudzeniem wywołanym przez usługę dostarczania strumieniami.

Własności TCP IIIa Przesyłanie z użyciem buforów. Programy użytkowe przesyłają strumienie danych obwodami wirtualnymi dzięki przekazywaniu kolejnych oktetów danych do oprogramowania protokołów. Program użytkowy przesyła dane w porcjach, które uważa za wygodne, a które mogą być nawet wielkości jednego oktetu. U odbiorcy oprogramowanie protokołów dostarcza oktety ze strumienia danych w takim samym porządku, w jakim zostały wysłane, udostępniając je odbierającemu programowi użytkowemu, po otrzymaniu i sprawdzeniu. Oprogramowanie protokołów ma swobodę przy dzieleniu strumienia na pakiety i może to robić niezależnie od tego, jak strumień jest dzielony przez program użytkowy.

Własności TCP IIIb W celu zwiększenia efektywności przesyłania i zminimalizowania ruchu w sieci przyjmuje się zwykle strategię czekania, aż uzbiera się tyle danych ze strumienia, żeby wypełnić datagram o rozsądnej wielkości zanim się go wyśle do intersieci. Dzięki temu, nawet jeśli program użytkowy generuje strumień po jednym bajcie naraz, przesyłanie danych przez intersieć może być dosyć efektywne. Podobnie jeśli program użytkowy wygeneruje bardzo duży blok danych, to oprogramowanie protokołów może podzielić go do transmisji na mniejsze porcje.

Własności TCP IIIc Dla tych programów użytkowych, w których dane powinny zostać dostarczone, nawet jeżeli bufor nie został wypełniony, udostępnia się mechanizm “wypychania” (ang. push), którego programy użytkowe używają do wymuszania przesyłania. Po stronie nadawcy operacja wypchnięcia wymusza na oprogramowaniu protokołów przesłanie wszystkich tych danych, które zostały dotąd wygenerowane, bez czekania na wypełnienie bufora. Po stronie odbiorcy zaś powoduje, że TCP udostępnia dane programowi użytkownika beż opóźnienia.

Własności TCP IV Brak strukturalizacji strumienia. Usługa przesyłania za pomocą strumieni TCP/IP nie uwzględnia strukturalizacji strumienia danych. Programy użytkowe wykorzystujące usługi przesyłania za pomocą strumieni muszą interpretować zawartość strumienia i jeszcze przed rozpoczęciem połączenia zgadzać się na format strumienia.

Własności TCP Va Połączenie w pełni dwukierunkowe. Połączenia zapewniane przez usługę przesyłania za pomocą strumieni TCP/IP są połączeniami w pełni dwukierunkowymi (ang. duplex). Z punktu widzenia programu użytkowego połączenie w pełni dwukierunkowe składa się z dwu niezależnych strumieni danych płynących w przeciwnych kierunkach bez żadnej jawnej interakcji między nimi. Usługa przesyłania za pomocą strumieni pozwala procesowi użytkownika na zatrzymanie przepływu w jednym z kierunków bez zakłócania przepływu w drugim, co czyni połączenie połączeniem połowicznie dwukierunkowym (ang. half duplex).

Własności TCP Vb Przy połączeniu w pełni dwukierunkowym oprogramowanie protokołów obsługujących może wysyłać nadawcy informacje kontrolne związane z jednym strumieniem w datagramach niosących dane w kierunku przeciwnym, co jest jego zaletą. Powoduje to zmniejszenie ruchu w sieci.

TCP jako komunikacja wirtualna

Niezawodne połączenie TCP I
Usługa dostarczania niezawodnymi strumieniami zapewnia, że dane wysyłane w strumieniu z jednej maszyny do drugiej nie są ani tracone, ani duplikowane. Zachodzi więc pytanie: “W jaki sposób oprogramowanie protokołów realizuje niezawodne przesyłanie, skoro bazowy system komunikacyjny oferuje tylko zawodne dostarczanie pakietów?”. Odpowiedź jest skomplikowana, ale większość protokołów oferujących niezawodność używa jednej podstawowej metody znanej jako pozytywne potwierdzanie z retransmisją (ang. positive acknowledgment with retransmission).

Niezawodne połączenie TCP II
Metoda ta wymaga, aby odbiorca komunikował się z nadawcą, wysyłając mu w momencie otrzymania danych komunikat potwierdzenia (ACK). Nadawca zapisuje sobie informację o każdym wysłanym pakiecie i przed wysłaniem następnego czeka na potwierdzenie. Oprócz tego nadawca uruchamia zegar w momencie wysyłania pakietu i wysyła ten pakiet ponownie, gdy minie odpowiedni czas, a potwierdzenie nie nadejdzie.

Niezawodne połączenie TCP III

Niezawodne połączenie TCP IV
Na kolejnym rysunku użyto tej samej formy diagramu co na poprzednim rysunku do pokazania, co się dzieje gdy pakiet został zgubiony lub gdy przekroczony został limit czasu. Po wysłaniu pakietu nadawca włącza zegar. Gdy mija określony czas, w czasie którego powinno nadejść potwierdzenie ACK nadawca przyjmuje, że pakiet został zagubiony i wysyła go ponownie.

Niezawodne połączenie TCP V

Niezawodne połączenie TCP VI
Ostatni problem związany z niezawodnością pojawia się, gdy bazowy system dostarczania duplikuje pakiety. Duplikowanie może się też pojawić, gdy sieci mają duże opóźnienia powodujące przedwczesne retransmisje. Rozwiązanie problemu duplikowania wymaga uważnego przemyślenia, gdyż mogą być zduplikowane zarówno pakiety jak i potwierdzenia. Zwykle niezawodne protokoły wykrywają zduplikowane pakiety, przyznając każdemu pakietowi kolejny numer i wymagając, aby odbiorca pamiętał numery odebranych pakietów.

Niezawodne połączenie TCP VII
W celu uniknięcia zamieszania spowodowanego opóźnionymi lub zduplikowanymi potwierdzeniami, protokoły z pozytywnym potwierdzaniem wysyłają w potwierdzeniach wartości kolejnych numerów, dzięki czemu odbiorca może prawidłowo wiązać potwierdzenia z pakietami.

Przesuwające się okna I
W celu uzyskania niezawodności nadawca wysyła pakiet, a przed wysłaniem następnego oczekuje na potwierdzenie odebrania. Dane pomiędzy maszynami płyną w danym momencie tylko w jednym kierunku i to nawet wtedy, kiedy sieć umożliwia jednoczesną komunikację w obu kierunkach. Ponadto sieć nie będzie używana, kiedy maszyny będą zwlekać z odpowiedziami np. podczas wyliczania sum kontrolnych. Takie rozwiązanie powoduje znaczne „marnowanie” przepustowości sieci.

Przesuwające się okna II
Technika przesuwającego się okna lepiej wykorzystuje przepustowość sieci, gdyż umożliwia wysyłanie wielu pakietów przed otrzymaniem potwierdzenia. W rozwiązaniu tym protokół zaleca umieszczenie na ciągu pakietów ustalonego rozmiaru okna i przesłanie wszystkich pakietów, które znajdują się w jego obrębie. Mówimy, że pakiet jest niepotwierdzony, jeżeli został wysłany, a nie nadeszło dla niego potwierdzenie. Liczba pakietów niepotwierdzonych w danej chwili jest wyznaczona przez rozmiar okna.

Przesuwające się okna III
Dla protokołu z przesuwającym się oknem , którego rozmiar jest np. równy 8, nadawca ma możliwość wysłania przed otrzymaniem potwierdzenia do 8 pakietów. Gdy nadawca odbierze potwierdzenie dla pierwszego pakietu, okno przesuwa się i zostaje wysłany następny pakiet. Okno przesuwa się dalej gdy przychodzą kolejne potwierdzenia.

Przesuwające się okna IV

Przesuwające się okna V
Pakiet dziewiąty może zostać wysłany gdy przyszło potwierdzenie dotyczące pierwszego pakietu. Retransmitowane są tylko te pakiety, dla których nie było potwierdzenia. Oczywiście protokół musi pamiętać, które pakiety zostały potwierdzone i utrzymuje oddzielny zegar dla każdego nie potwierdzonego pakietu. Gdy pakiet zostanie zgubiony lub zostaje przekroczony czas nadawca wysyła ten pakiet jeszcze raz.

Przesuwające się okna VI
Poprawa uzyskiwana przy protokołach z przesuwającymi się oknami zależy od rozmiaru okna i szybkości, z jaką sieć akceptuje pakiety. Gdy rozmiar okna wynosi 1, protokół z przesuwającym się oknem jest tym samym, co nasz zwykły protokół z potwierdzaniem. Zwiększając rozmiar okna, możemy w ogóle wyeliminować momenty nieaktywności sieci. Oznacza to, że w sytuacji stabilnej nadawca może przesyłać pakiety tak szybko, jak szybko sieć może je przesyłać.

Przesuwające się okna VII

Przesuwające się okna VIII
Poniższy rysunek pokazuje przykład przesyłania trzech pakietów przy użyciu protokołu z przesuwającym się oknem. Istotne jest tutaj, że nadawca może przesłać wszystkie pakiety z okna bez oczekiwania na potwierdzenie.

Segment TCP I Mianem segmentu określa się jednostkową porcję danych przesyłanych między oprogramowaniem TCP na różnych maszynach. Segmentów używa się również do ustanawiania połączenia, do przesyłania danych, do potwierdzania, do wysyłania propozycji okien oraz do zamykania połączeń. W związku z tym, że TCP korzysta z możliwości “jazdy na barana”, potwierdzenie przepływające z maszyny A do maszyny B może podróżować w tym samym segmencie, co dane z maszyny A do B i to nawet wtedy, gdy potwierdzenie odnosi się do danych przesyłanych z B do A. Poniższy rysunek pokazuje format segmentu TCP.

Segment TCP II

Segment TCP III Każdy segment podzielony jest na dwie części: nagłówek i dane, które się za nim znajdują. Nagłówek, nazywany nagłówkiem TCP, zawiera spodziewane informacje identyfikacyjne oraz kontrolne. Pola PORT NADAWCY i PORT ODBIORCY zawierają numery portów TCP, które identyfikują programy użytkowe na końcach połączenia. Pole NUMER PORZĄDKOWY wyznacza pozycję danych segmentu w strumieniu bajtów nadawcy.

Segment TCP IV Pole NUMER POTWIERDZENIA wyznacza numer oktetu, który nadawca spodziewa się otrzymać w następnej kolejności. Zwróćmy uwagę, że NUMER PORZĄDKOWY odnosi się do strumienia płynącego w tym samym kierunku co segment, zaś NUMER POTWIERDZENIA odnosi się do strumieni płynących w kierunku przeciwnym. Pole DŁUGOŚĆ NAGŁÓWKA zawiera liczbę całkowitą, która określa długość nagłówka segmentu mierzoną w wielokrotnościach 32 bitów. Jest ono konieczne gdyż pole OPCJE ma zmienną długość.

Segment TCP V Pole ZAREZERWOWANE jest pozostawione do wykorzystania w przyszłości. Ponieważ niektóre segmenty mogą przenosić tylko potwierdzenia, inne również dane, inne zaś zawierają prośby o ustanowienie lub zamknięcie połączenia - pole BITY KODU zawiera informację o przeznaczeniu zawartości segmentu.

Segment TCP VI Przy każdym wysłaniu segmentu oprogramowanie TCP proponuje ile danych może przyjąć, umieszczając rozmiar swojego bufora w polu OKNO. Pole to zawiera 16-bitową liczbę całkowitą bez znaku, zapisaną w sieciowym standardzie uporządkowania bajtów. Propozycje wielkości okna to kolejny przykład jeżdżenia “na barana”, gdyż towarzyszą one wszystkim segmentom, w tym segmentom zawierającym dane i przenoszącym samo potwierdzenie.

Segment TCP – szczegóły I
Pole port źródłowy (16 bitów) i pole port docelowy (16 bitów) zawierają numery portów procesów aplikacyjnych korzystających z usług TCP. Kombinacja tych numerów z adresami sieciowymi określa parę gniazd tworzących połączenie protokołu TCP.

Segment TCP – szczegóły II
Pole numer sekwencyjny (32 bity) zawiera numer sekwencyjny pierwszego bajtu danych w segmencie. Ta wartość określa pozycję segmentu w strumieniu bajtów. Podczas ustanawiania połączenia, i jeśli bit syn w polu znaczniki jest ustawiony na 1, to w tym polu zawarty jest inicjujący numer sekwencyjny ins, od którego rozpoczyna się numerację bajtów w połączeniu. Zatem pierwszy wysłany bajt ma numer ins + 1.

Segment TCP – szczegóły III
Pole numer potwierdzenia (32 bity) zawiera numer sekwencyjny następnego oczekiwanego bajtu po stronie odbiorczej. Jednocześnie jest to potwierdzenie poprawnego odbioru bajtów o numerach sekwencyjnych mniejszych od zawartego w tym polu. Potwierdzenia mówią nadawcy ile bajtów danych zostało już poprawnie odebranych.

Segment TCP – szczegóły VI
Pole długość nagłówka (4 bity) określa liczbę 32 - bitowych słów w nagłówku segmentu TCP. Tym samym określone zostaje miejsce, w którym rozpoczynają się dane. Pole to ma takie znaczenie tylko wtedy, gdy bit ack równy jest 1. Pole rezerwa (6 bitów) jest przeznaczone dla przyszłych zastosowań. Zawiera same zera.

Segment TCP – szczegóły V
Pole znaczniki składa się z sześciu bitów sterujących: UGR - wskazuje na ważność pola wskaźnik pilności, ACK - wskazuje na ważność pola numer potwierdzania, PSH - wskazuje na działanie funkcji wymuszającej wysyłanie segmentu, RST - wyzerowanie połączenia, SYN - wskazuje, że w polu numer sekwencyjny umieszczony jest inicjujący numer sekwencyjny INS. Jest on przeznaczony do synchronizacji numerów sekwencyjnych w fazie ustanowienia połączenia. FIN - wskazuje, że nadawca nie ma nic więcej do nadania - sygnał końca danych.

Segment TCP – szczegóły VI
Pole okno (16 bitów) określa liczbę bajtów jaka może jeszcze zaakceptować odbiorczy moduł TCP. Pole suma kontrolna jest 16 - bitowym jedynkowym uzupełnieniem jedynkowo uzupełnionej sumy wszystkich 16 - bitowych słów w segmencie. Ta suma obejmuje zarówno nagłówek jak i dane segmentu. Pole wskaźnik pilności (16 bitów) jest interpretowane tylko wtedy, gdy bit UGR jest równy 1. Pole to zawiera numer sekwencyjny bajtu następującego po pilnych danych.

Segment TCP – szczegóły VII
Pole opcje ma długość zmienna będąca wielokrotnością 8 bitów. Zawiera ono numery opcji - każdy numer zapisany w jednym bajcie. Dla protokołu TCP zdefiniowano trzy opcje: 0 - koniec listy opcji, 1 - brak działania, 2 - maksymalna długość segmentu. Pole wypełnienie uzupełnia nagłówek do wielokrotności 32 bitów.

Nawiązywanie połączenia TCP – szczegóły I
Połączenie TCP jest nawiązywane za pomocą trójstopniowej procedury. Ma ona na celu zsynchronizowanie numerów sekwencji i potwierdzenia po obu stronach połączenia oraz wymianę rozmiarów okna TCP. Proces przebiega w następujących fazach:

Nawiązywanie połączenia TCP – szczegóły II
1. Klient wysyła segment TCP do serwera, w którym zawarty jest początkowy numer sekwencji i rozmiar okna, wskazujący rozmiar bufora po stronie klienta. 2. Serwer odsyła z powrotem segment TCP zawierający wybrany przez siebie numer sekwencji i rozmiar okna, wskazujący rozmiar bufora po stronie serwera. 3. Klient wysyła segment TCP z potwierdzeniem numeru sekwencji wybranego przez serwer.

Nawiązywanie połączenia TCP – szczegóły III
TCP używa analogicznej procedury przy rozłączaniu połączenia. Gwarantuje to, że obydwa hosty zakończyły transmisję i że wszystkie dane zostały odebrane. W ten sposób zostaje ustanowione połączenie wirtualne między dwoma modułami TCP i mogą zostać przesyłane segmenty z danymi. Segmenty te mogą być przesyłane tym połączeniem w obu kierunkach, ponieważ TCP umożliwia transfer danych między dwoma modułami w trybie dupleksowym. Dla zapewnienia niezawodnej transmisji TCP wykorzystuje sekwencyjna numerację bajtów oraz mechanizm pozytywnych potwierdzeń z retransmisja.

Nawiązywanie połączenia TCP – szczegóły IV
Nadawczy moduł TCP dokonuje retransmisji danych do czasu, aż otrzyma potwierdzenie poprawnego ich przyjęcia przez odbiorczy moduł TCP. Rozpoczęcie retransmisji uwarunkowane jest przekroczeniem wczesniej ustalonego czasu oczekiwania na nadejscie potwierdzenia. Po stronie odbiorczej poprawnosć odbioru danych sprawdzana jest przy użyciu pola suma kontrolna znajdujacego się w nagłówku segmentu. Jeżeli dane sa akceptowane to moduł TCP wysyła zwrotnie pozytywne potwierdzenie. Jest ono zawarte w polu numer potwierdzenia. Wszystkie bajty danych o numerach sekwencyjnych mniejszych od wartosci zawarte w tym polu zostały odebrane poprawnie.

Maski podsieci I Maska podsieci składa się podobnie jak adres IP z 4 bajtów i używana jest do wydzielenia części adresu odpowiadającej za identyfikację podsieci i części odpowiadającej za identyfikację komputera z adresu IP wchodzącego w skład tej podsieci. Jeśli bit w masce to jedynka, to odpowiadający mu bit w adresie IP jest interpretowany jako bit adresu podsieci. Natomiast jeśli bit maski wynosi zero, oznacza to, że należy on do części adresu określającej komputer. Podsieć jest znana wyłącznie lokalnie i dla całej reszty Internetu adres jest interpretowany jako standardowy.

Maski podsieci II Na przykład maska podsieci powiązana z adresem sieciowym klasy B wynosi Najczęściej używana maska podsieci rozszerza część sieciową adresu klasy B na dodatkowy bajt. Maska ma wtedy postać ; wszystkie bity w trzech pierwszych bajtach są jedynkami, a w ostatnim zerami. Pierwsze dwa bajty definiują sieć klasy B, następny stanowi adres podsieci, a osta-tni bajt identyfikuje komputer w tej podsieci. Opisany przykład obrazuje poniższy rysunek.

Maski podsieci III

Przykłady stosowania masek
Adres IP Maska podsieci Interpretacja komputer 1 w podsieci komputer 4 w podsieci komputer 2 w podsieci komputer 4.5 w podsieci komputer w podsieci

Połączenia i porty I Protokół TCP umożliwia wielu działającym na jednej maszynie programom użytkowym jednoczesne komunikowanie się oraz rozdziela między programy użytkowe przybywające pakiety TCP. Podobnie jak UDP, TCP używa numerów portów protokołu do identyfikacji w ramach maszyny końcowego odbiorcy. Każdy z portów ma przypisaną małą liczbę całkowitą, która jest używana do jego identyfikacji.

Połączenia i porty II Porty TCP są jednak bardziej złożone, gdyż dany numer nie odpowiada bezpośrednio pojedynczemu obiektowi. TCP działa wykorzystując połączenia, w których obiektami są obwody wirtualne a nie poszczególne porty. Tak więc podstawowym pojęciem TCP jest pojęcie połączenia, a nie portu. Połączenia są identyfikowane przez parę punktów końcowych.

Połączenia i porty III TCP definiuje punkt końcowy jako parę liczb całkowitych (węzeł, port), gdzie węzeł oznacza adres IP węzła, a port jest portem TCP w tym węźle. Np. punkt końcowy ( , 25) oznacza port 25 maszyny o adresie IP W efekcie może istnieć połączenie np. pomiędzy: ( , 1069) oraz ( , 25), w tym samym czasie może też istnieć ( , 1184) oraz ( , 25). W związku z tym, że TCP identyfikuje połączenie za pomocą pary punktów końcowych, dany numer portu może być przypisany do wielu połączeń na danej maszynie.

IP next generation (w skrócie IPng) lub IP wersja 6 I
Dłuższe adresy. Nowe rozmiary adresów to najbardziej znacząca zmiana. IPv6 powiększa cztery razy rozmiar adresu IP z 32 bitów do 128 bitów. Przestrzeń adresowa IPv6 jest tak duża, że nie może być wyczerpana w przewidywalnej przyszłości. Elastyczny format nagłówka. IPv6 używa całkowicie nowego formatu datagramu, niekompatybilnego z poprzednim. Inaczej niż w przypadku IPv4, w którym nagłówek datagramu ma ustalony format – wszystkie pola za wyjątkiem opcji zajmują ustaloną liczbę oktetów i pozycję – IPv6 używa zbioru opcjonalnych nagłówków.

IP next generation (w skrócie IPng) lub IP wersja 6 II
Poprawione opcje. Podobnie jak IPv4, IPv6 pozwala aby datagramy zawierały opcjonalne informacje sterujące. IPv6 zawiera nowe opcje, które dają dodatkowe możliwości niedostępne w IPv4. Wsparcie dla rezerwowania zasobów. IPv6 zastępuje specyfikowanie typu obsługi IPv4 mechanizmem, który umożliwia wcześniejsze rezerwowanie zasobów sieciowych. W szczególności nowy mechanizm stanowi podstawę programów użytkowych służących np. do przekazywania obrazów w czasie rzeczywistym, które wymagają gwarantowanej przepustowości oraz stałego opóźnienia.

IP next generation (w skrócie IPng) lub IP wersja 6 III
Zapewnienie rozszerzalności protokołu. Być może najbardziej znaczącą zmianą w IPv6 jest odejście od idei protokołu, który w pełni specyfikuje wszystkie szczegóły, do idei, w której umożliwia się dodawanie funkcji. Możliwość rozszerzania to potencjał, który pozwoli IETF dostosowywać protokół do zmian w sprzęcie sieciowym oraz świecie programów użytkowych.

IP next generation (w skrócie IPng) lub IP wersja 6 IV

Sprzęt i oprogramowanie sieciowe

Similar presentations

Presentation on theme: "Sprzęt i oprogramowanie sieciowe"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Sprzęt i oprogramowanie sieciowe

Similar presentations

Presentation on theme: "Sprzęt i oprogramowanie sieciowe"— Presentation transcript:

Similar presentations

About project

Feedback