Achiziia i Prelucrarea Datelor__________________________________Comunicatii TCP/IP

Comunicaii TCP/IP
Modelul TCP/IP (Transmission Control Protocol/Internet Protocol) a fost creat de US DoD (US Department of Defence - Ministerul Aprrii Naionale al Statelor Unite) din necesitatea unei reele care ar putea supravieui n orice condiii. DoD dorea ca, atta timp ct funcionau maina surs i maina destinaie, conexiunile s rmn intacte, chiar dac o parte din maini sau din liniile de transmisie erau brusc scoase din funciune. Era nevoie de o arhitectur flexibil, deoarece se aveau n vedere aplicaii cu cerine divergente, mergnd de la transferul de fiiere pn la transmiterea vorbirii n timp real. Aceste cerine au condus la alegerea a patru niveluri pentru modelul TCP/IP: Aplicaie, Transport, Reea (sau Internet) i Acces la Reea. Nivelul Aplicatie nu este identic cu cel din modelul ISO-OSI. Acesta include ultimele trei niveluri superioare din stiva OSI. Acestea au fost comasate pentru a putea fi tratate la un loc toate problemele legate de protocoale de nivel nalt, fie ele de reprezentare, codificare sau control al dialogului. El conine toate protocoalele de nivel nalt. Primele protocoale de acest gen includeau terminalul virtual (TELNET), transfer de fiiere (FTP) i pota electronic (SMTP). Pe parcursul anilor la aceste protocoale s-au adugat multe altele, aa cum sunt: DNS (Domain Name Service), NNTP, HTTP etc. Nivelul Transport este identic cu cel din modelul OSI, ocupndu-se cu probleme legate de siguran, control al fluxului i corecie de erori. El este proiectat astfel nct s permit conversaii ntre entitile pereche din gazdele surs, respectiv, destinaie. n acest sens au fost definite dou protocoale capt-la-capt. Primul din ele este TCP (Trasmission Control Protocol). El este un protocol sigur orientat pe conexiune care permite ca un flux de octei trimii de pe o main s ajung fr erori pe orice alt main din inter-reea. Acest protocol fragmenteaz fluxul de octei n mesaje discrete i paseaz fiecare mesaj nivelului internet. TCP trateaz totodat controlul fluxului pentru a se asigura c un emitor rapid nu inund un receptor lent cu mai multe mesaje dect poate acesta s prelucreze. Al doilea protocol din acest nivel, UDP (User Datagram Protocol), este un protocol nesigur, fr conexiuni, destinat aplicaiilor care doresc s utilizeze propria lor secveniere i control al fluxului. Protocolul UDP este de asemenea mult folosit pentru interogri rapide ntrebare-rspuns, client-server i pentru aplicaii n care comunicarea prompt este mai importatnt dect comunicarea cu acuratee, aa cum sunt aplicaiile de transmisie a vorbirii i a imaginilor video. Nivelul Reea (Internet) - scopul nivelului este de a asigura transmiterea pachetelor de la orice surs din reea i livrarea lor ctre o destinaie independent de calea i reelele pe care lea strbtut pentru a ajunge acolo. Determinarea drumului optim i comutarea pachetelor au loc la acest nivel. Nivelul Internet definete oficial un format de pachet i un protocol numit IP (Internet Protocol). Sarcina nivelului Internet este s livreze pachete IP ctre destinaie. Problemele majore se refer la dirijarea pachetelor i evitarea congestiei. n consecin este rezonabil s presupunem c nivelul Internet din TCP/IP funcioneaz asemantor cu nivelul reea din OSI. Nivelul Acces la reea se ocup cu toate problemele legate de transmiterea efectiv a unui pachet IP pe o legtur fizic, incluznd i aspectele legate de tehnologii i de medii de transmisie, adic nivelurile OSI Legtur de date i Fizic. Modelul de referin TCP/IP nu spune mare lucru despre ce se ntmpl acolo, ns menioneaz c gazda trebuie s se lege la reea, pentru a putea trimite pachete IP, folosind un anumit protocol. Acest protocol nu este definit i variaz de la gazd la gazd i de la reea la reea.

Achiziia i Prelucrarea Datelor__________________________________Comunicatii TCP/IP

Biblioteca TCP/IP n CVI

Modelul de comunicare folosind TCP/IP pus la dispoziie de CVI implic un client i un server pentru fiecare conexiune. Exist posibilitatea ca mai muli clieni s se conecteze la acelai server i respectiv un PC poate avea mai multe servere, dar pentru comunicaie de date ntre dou sisteme este suficient s fie un server si un client. Un server TCP poate trimite i recepiona informaii de la una sau mai multe aplicaii de tip client prin intermediul reelei, la fel i n cazul invers. Un server care a fost nregistrat rmne n ateptarea cererilor de la diferii clieni. O aplicaie poate fi proiectat astfel nct s poat ndeplini, funcie de necesiti, att funcia de server ct i pe cea de client. Sub sistemul de operare Windows avem posibilitatea ca pe aceeai main s se poat executa simultan i un client i un server. Pentru a realiza comunicarea de date ntre cele dou sisteme server client, mediul CVI pune la dispoziie diverse funcii specializate pentru implementarea diferitelor operaii: nregistrarea serverului, conectarea clientului, citirea datelor, transmiterea datelor, preluarea erorilor etc. n cele ce urmeaz se vor prezenta att modul de lucru, ct i funciile necesare realizrii unui server, respectiv client.

Server TCP/IP
Dac aplicaia trebuie s fie de tip server atunci pentru iniializare este necesar nregistrarea serverului folosind funcia RegisterTCPServer. Aceast funcie va realiza asocierea dintre programul aplicaie i perechea definitorie nume server + numr port . Funcia de rspuns (callback) ataat serverului va fi apelat de fiecare dat cnd apare nevoia unei comunicaii fie ntr-o direcie, fie n alta. Aceast funcie trebuie s aib urmtorul prototip: int CallbackName(unsigned handle, int xType, int errCode, void *callbackData); Descrierea parametrilor: - handle: acest parametru reprezint identificatorul liniei de comunicaie ntre client i server. OBSERVAIE: mediul CVI atribuie un identificator liniei de comunicaie la conectarea unui client la server. Acest identificator de comunicaie va fi pasat ca valoare n parametrul handle la autoapelul funciei de callback mai sus prezentat. Acest identificator (variabila handle) va trebui salvat ntr-o variabil global utilizat ulterior n operaiile de write i read (transmisie/recepie) ale serverului; - xType: specific tipul de eveniment care a generat autoapelul funciei de callback a serverului. Poate avea valorile TCP_CONNECT, TCP_DISCONNECT, TCP_DATAREADY (a se vedea descrierea de mai jos); - errCode: la deconectarea unui client (xType = TCP_DISCONNECT ) acest parametru specific dac clientul a fost deconectat datorit unei probleme pe mediul de comunicare sau dac clientul s-a deconectat n mod intenionat; - callbackData: parametru de 4 octei transmii de fiecare dat cnd se autoapeleaz funcia de callback a serverului (de obicei se las 0); n tabelul urmtor sunt prezentate tipurile de evenimente care genereaz autoapelul funciei de callback a serverului, precum i descrierile acestora:

Achiziia i Prelucrarea Datelor__________________________________Comunicatii TCP/IP

Tabel 1 Evenimentele care genereaz autoapelul funciei de callback a serverului

Nr. Crt. 1. 2. 3.

Eveniment (xType) TCP_CONNECT

Descriere

Acest tip de eveniment specific faptul c un client s-a conectat la server TCP_DISCONNECT Acest tip de eveniment specific faptul c un client s-a deconectat de la server TCP_DATAREADY Acest tip de eveniment semnalizeaz faptul c s-au recepionat date de la client. Se va utiliza funcia dedicat de citire a datelor (a se vedea mai jos)

Pentru a determina ce tip de eveniment a generat autoapelul funciei de callback a serverului, n interiorul funciei va trebui s se fac teste asupra variabilei xType, care menine tipul de eveniment. n cazul in care xType este TCP_CONNECT, aplicaia server trebuie s salveze identificatorul comunicaiei (variabila handle) ntr-o variabil global utilizat ulterior n operaiile de transmisie/citire a datelor la server. De asemenea, n urma procesului de conectare a unui client, serverul poate prelua informaii despre numele i adresa de IP a clientului. Funciile utilizate n acest caz sunt: GetTCPPeerAddr i GetTCPPeerName. n cazul in care xType este TCP_DISCONNECT, aplicaia server poate actualiza o csu de stare a comunicaiei cu clientul, semnaliznd deconectarea acestuia. n cazul in care xType este TCP_DATAREADY, aplicaia server trebuie s preia datele recepionate de la client prin utilizarea funciilor specializate ale serverului (prezentate mai jos). n urma procesului de nregistrare a serverului, aplicaia server poate furniza utilizatorului diverse informaii ale acestui server, cum ar fi: numele serverului, adresa de IP, portul. Pentru obinerea acestor informaii se pot utiliza funcii de librarie, cum ar fi: GetTCPHostAddr, GetTCPHostName. Pentru a opri un server TCP/IP pecedent nregistrat se va folosi funcia UnregisterTCPServer. nafar de nregistrarea/oprirea unui server TCP/IP, orice aplicaie server trebuie s permit transmisia i recepia datelor. Recepia datelor (operaia de read) n cadrul unei aplicaii server n CVI se realizeaz prin utilizarea funciei de bibleotec ServerTCPRead. Datorit faptului c procesul de recepie a datelor de partea serverului este un proces asincron fa de starea aplicaiei, funcia ServerTCPRead va trebui s se apelez n funcia de callback a serverului, atunci cnd sunt date disponibile de la client. Transmiterea datelor de la client la server se realizeaz utiliznd funcia de bibleotec ServerTCPWrite. Aceast funcie se poate apela ori de cte ori este necesar transmisia de date. A se avea n vedere c aceast funcie utilizeaz identificatorul de comunicaie precedent salvat n funcia de callback a serverului.

Client TCP/IP
Pentru a putea conecta un client TCP dintr-o aplicaie CVI la un server trebuiesc cunoscute o serie de informaii despre serverul la care se dorete conectarea. Prima informaie se refer la numele serverului sau adresa lui de IP asociat acestui nume. Ca tehnic de proiectare a aplicaiei se recomand folosirea numelui serverului (ca de exemplu: localhost, S3302) sau cererea acestuia de la utilizator. Acest lucru se datoreaz faptului c adresa unui server se poate schimba dar numele lui de obicei nu. Mai este nevoie i de numrul portului la care poate fi accesat respectivul serviciu n cadrul serverului. Pe un singur PC pot fi acitve mai multe servere TCP, atta timp ct porturile

Achiziia i Prelucrarea Datelor__________________________________Comunicatii TCP/IP pe care s-au nregistrat acele servere difer. Din acest motiv, aplicaia client va trebui s disting din lista de servere active un singur server de interes prin utilizarea portului corespunztor. nainte de orice operaie de comunicare (transmisie/recepie) clientul trebuie s se conecteze la server, utiliznd funcia ConnectToTCPServer. Funcia are urmtorul prototip: int ConnectToTCPServer (unsigned int *conversationHandle, unsigned int portNumber, char *serverHostName, tcpFuncPtr clientCallbackFunction, void *callbackData, unsigned int timeout); Descrierea parametrilor: - conversationHandle: funcia ConnectToTCPServer creeaz un canal de comunicaie cu serverul i returneaz un identificator al comunicaiei n aceast variabil; - portNumber: portul pe care este nregistrat serverul - serverHostName: un ir de caractere care reprezint numele serverului (ex: localhost, S3302) sau adresa de ip a acestuia (ex: 192.168.247.90); - clientCallback function: funcia de callback a clientului; va fi utilizat pentru recepionarea datelor de la server i pentru depistarea deconectrii serverului. - callbackData: parametru de 4 octei transmii de fiecare dat cnd se apeleaz funcia (de obicei se las 0); - timeout: numrul de milisecunde care se ateapt pentru reapelul funciei n caz c operaia de conectare a euat Dup cum s-a prezentat i mai sus, funcia de callback a clientului va fi utilizat pentru recepia datelor de la server i pentru determinarea deconectrii serverului. Prototipul i parametrii funciei sunt identici cu cei ai funciei de callback pentru server, aadar nu vor mai fi prezentai n acest subcapitol. Exist o diferen totui fa de evenimentele care pot genera autoapelul funciei de callback: n cazul clientului, evenimentel pot fi doar dou: TCP_DISCONNECT i TCP_DATAREADY. Mai jos se prezint un tabel cu descrierea evenimentelor: Nr. Crt. 1. 2. Eveniment (xType) Descriere

TCP_DISCONNECT Acest tip de eveniment specific faptul c serverul s-a deconectat TCP_DATAREADY Acest tip de eveniment semnalizeaz faptul c s-au recepionat date de la server. Se va utiliza funcia dedicat de citire a datelor (a se vedea mai jos)

Ca i n cazul aplicaiei server, n urma procesului de conectare la server aplicaia client poate furniza utilizatorului diverse informaii ale serverului, cum ar fi: numele serverului, adresa de IP, portul. Pentru obinerea acestor informaii se pot utiliza funcii de librarie, cum ar fi: GetTCPPeerAddr i GetTCPPeerName. De asemenra, dup conectarea la server, aplicaia client poate furniza date cu privire la adresa i numele clientului, utiliznd funciile GetTCPHostAddr, GetTCPHostName. Pentru a opri un client TCP/IP precedent conectat la un server se poate utiliza funcia de librrie DisconnectFromTCPServer. Operaiile de comunicaie (transmisie/recepie) ulterioare deconectrii de la server vor fi invalide (vor genera erori). Comunicaia cu serverul se realizeaz prin utilizarea funciilor de librrie ClientTCPWrite (pentru transmisie) i ClientTCPRead (recepie). Dac transmisia datelor se poate face oriunde n aplicaie, atunci cnd este nevoie, recepia datelor de la server trebuie s fie fcut n funcia de callback a clientului, pe evenimentul TCP_DATAREADY.

Achiziia i Prelucrarea Datelor__________________________________Comunicatii TCP/IP

Tratarea erorilor
Biblioteca TCP/IP din cadrul medului de programare Labwindows/CVI pune la dispoziia programatorului mecanisme de a trata erorile generate de apelurile funciilor TCP/IP. Una dintre funciile care returneaz informaii detaliate cu privire la erorile aprute n urma apelului oricrei funcii de librrie TCP/IP este funcia GetTCPSystemErrorString. n funcie de codul de eroare returnat la apelul unei funcii TCP/IP, aceast funcie decodific valoarea erorii si va selecta unul din mesajele de eroare corespunztor problemei aprute. Acest mesaj poate fi utilizat pentru a ntiina utilizatorul despre eventualele probleme de comunicaie. O aplicaie de tip server sau client corect proiectat trebuie s in seama de eventualele erori care pot aprea n procesul de comunicaie. De exemplu, dac un client nu reuete din varii motive s se conecteze la un server, atunci operaiile subsidiare ale aplicaiei client trebuiesc inactivate pentru a evita eventualele mesaje de sistem sau chiar funcionarea inadecvat a aplicaiei.