ΔΙΑΓΡΑΜΜΑ ΕΡΓΑΣΙΑΣ

ΒΙΒΛΙΟΓΡΑΦΙΑ

Andrew S. Tanenbaum, Δίκτυα Υπολογιστών, εκδ. Παπασωτηρίου

Jesse Liberty, Εγχειρίδιο C++, εκδ. Μ. Γκιούρδας

Π.Κ. Γαρίδης και Εμ.Ν.Δεληγιαννάκης, Σύγχρονο Λεξικό Πληροφορικής Directory of Computing, εκδ. Δίαυλος

Ρίζος Γεώργιος, Σημειώσεις Δίκτυα ΙΙ (ΣΤ΄ εξάμηνο)

Κ. Λάππας, Σημειώσεις Πρωτόκολλα Διαδικτύων

Allman M., Paxson V., and Stevens W. R. 1999. "TCP Congestion Control," RFC 2581

Allman M., Floyd S., and Partridge C. 2002. "Increasing TCP's Initial Window," RFC 3390

Anthony J., Ohlund J. 2002, “Network Programming for Microsoft Windows”, Microsoft Press

Alec Woo, Siddharth Seth, Tim Olson, Jie Liu, and Feng Zhao. 2005. "A Spreadsheet Approach to Programming and Managing Sensor Networks," Technical Report MSR-TR-2005-162, Microsoft Research, Redmond, WA 98052
Bjarne Stroustroup 1997, “The C++ Programming Language, 3rd Edition”, Addison-Wesley, Reading, MA

Garcia-Zubia J., Lopez de Ipina D., Orduna P. 2005, “Towards a canonical Software Architecture for Multidevice Weblabs”, Industrial Electronics Society, 2005. IECON 2005. 32nd Annual Conference of IEEE, 6 pp-. ISBN: 0-7803-9252-3

Garcia-Zubia J., Lopez de Ipina D., Orduna P. 2005, “Evolving towards better architectures for remote laboratories: a practical case”, iJoe International Journal of Online Engineering- www.i-joe.org Vol 1, no. 2 (2005)

Jacobson V., Braden R. T. and Borman D. A. 1992. "TCP Extensions for High Performance," RFC 1323

Jie Liu, Elaine Cheong, and Feng Zhao. 2005. "Semantics-Based Optimization Across Uncoordinated Tasks in Networked Embedded Systems," in Proceedings of the 5th ACM Conference on Embedded Software (EMSOFT 2005), Jersey City, New Jersey

Jie Liu and Feng Zhao, "Towards Semantic Services for Sensor-Rich Information Systems," in Second IEEE/CreateNet International Workshop on Broadband Advanced Sensor Networks (Basenets 2005), Boston, MA, Oct. 3, 2005.

Masuda Y., Sekimoto M., Nambu M., Higashi Y., Fujimoto T., Chihara K., Tamura Y., 2005, “An unconstrained monitoring system for home rehabilitation” Engineering in Medicine and Biology Magazine IEEE, 2005. Volume: 24, Issue: 4, p 43- 47 ISSN: 0739-5175

Postel J. B. 1981c. "Transmission Control Protocol," RFC 793

Paxson V. and Allman M. 2000. "Computing TCP's Retransmission Timer," RFC 2988

Schoellhammer T., Greenstein B., Osterweil E., Wimbrow M., Estrin D. 2004 “Lightweight temporal compression of microclimate datasets ,“ Conference on Local Computer Networks No29, Tampa FL, (16/11/2004) 2004, pp. 516-524, [Note(s) : XXX-781 p.] ISBN: 0-7695-2260-2. IEEE Computer Society, Los Alamitos CA

Stathopoulos T., Lewis G., Heidermann J., Estrin D. 2006, “Mote Herding for Tiered Wireless Sensor Networks” In USENIX Tech. Conf. 2006

Stevens R., Fenner B. and Rudoff A.M. 2003, “Unix Network Programming”, Addison-Wesley, Reading, MA

Stevens W. Richard 1994,”TCP/IP Illustrated” Addison-Wesley Longman, January 1994

Warren Young (2006) WINSOCK Programmers’ FAQ HOME PAGE [online]. Available from: http://tangentsoft.net/wskfaq/articles/debugging-tcp.html [date: 25-06-06]

Whitehouse Kamin, Feng Zhao, Jie Liu. 2006 “Semantics Streams: A Framework for Compassable Semantic Interpretation of Sensor Data” K. Romer, H. Karl and F Mattern (Eds): EWSN 2006, LNCS 3868, pp. 5-20, 2006. Spinger-Verlag Berlin Heidelberg 2006

ΓΛΩΣΣΑΡΙΟ

ACK
Χαρακτήρας αναγνώρισης. Χαρακτήρας ελέγχου, που δείχνει ότι η πληροφορία που μεταδόθηκε παρελήφθη από τη συσκευή-αποδέκτη.

FIN
ένα bit ελέγχου (finis) που καταλαμβάνει έναν αριθμό ακολουθίας, ο οποίος δείχνει ότι ο αποστολέας δεν θα στείλει άλλους χαρακτήρες δεδομένων ή χαρακτήρες ελέγχου.
IP
Πρωτόκολλο Διαδικτύου.
Packet
Ένα πακέτο δεδομένων με μια κεφαλίδα που μπορεί να είναι ή να μην είναι λογικά πλήρης. Περισσότερο το φυσικό παρά το λογικό πακετάρισμα των δεδομένων.
Port
Το τμήμα ενός socket που προσδιορίζει το λογικό κανάλι εισόδου ή εξόδου μιας διαδικασίας συσχετιζόμενη με τα δεδομένα.
Seagment
Μια λογική μονάδα των δεδομένων.
Socket
Μια διεύθυνση που περιλαμβάνει συγκεκριμένα ένα αναγνωριστικό θύρας, δηλαδή η αλληλουχία μιας διεύθυνσης Διαδικτύου με μια θύρα TCP.
SYN
Ένα bit ελέγχου στο εισερχόμενο τμήμα, που καταλαμβάνει έναν αριθμό ακολουθίας, το οποίο χρησιμοποιείται στην έναρξη μιας σύνδεσης, για να δείξει από πού θα αρχίσει η αρίθμηση της ακολουθίας.
TCP
Πρωτόκολλο ελέγχου μετάδοσης: Ένα πρωτόκολλο τύπου host to host για την αξιόπιστη επικοινωνία σε περιβάλλοντα διαδικτύου.

8. ΣΥΜΠΕΡΑΣΜΑΤΑ

Εν κατακλείδι, κάποιος μπορεί να κρίνει καλύτερα τη σημασία των microservers και τις αιτίες για την ανάπτυξή τους. Αυτός που αναπτύχθηκε εδώ είναι ένας με περιορισμένες δυνατότητες, αλλά έχει τη δυνατότητα να γίνει μια πλατφόρμα για μια πληρέστερη λύση. Η αξία του βρίσκεται στην απλότητά του, ένας παράγοντας που τον καθιστά εύκολο να εφαρμοστεί μόλις αποκτηθεί η βασική γνώση. Μετά από ορισμένες μετατροπές και διαφορετική πορεία σχεδιασμού θα μπορούσε να εξυπηρετήσει άλλο στόχο. Μια τέτοια πρόταση θα μπορούσε να είναι η χρήση ενός διαφορετικού λειτουργικού συστήματος. Η εφαρμογή του σε ένα σύστημα POSIX αντί των Windows CE θα μπορούσε να περιορίσει τα κόστη αφού αυτά τα συστήματα διανέμονται στο πλαίσιο της συμφωνίας αδειών GNU και είναι πολύ ευκολότερο να αποκτηθούν και να παραμετροποιηθούν για να ανταποκριθούν σε συγκεκριμένες ανάγκες. Αλλά μια και το WINSOCK API είναι απόγονος των BSD sockets και τη λειτουργίες που χρησιμοποιήθηκαν από το WINSOCK σε αυτήν την εφαρμογή είναι ίδιο με αυτές των BSD sockets API , λίγες αλλαγές χρειάζεται να γίνουν προκειμένου να παραχθεί μια συμβατή λύση. Τελικά το μικρό του μέγεθος, η μικρή κατανάλωση μνήμης και CPU το κάνουν μια επιτυχία.

7. ΑΞΙΟΛΟΓΗΣΗ

Όλα τα παραπάνω αποδεικνύουν ότι ο μServer είναι αρκετά αξιόπιστος στην λειτουργία του και αρκετά μικρός στο μέγεθος ώστε να θεωρείται μια βιώσιμη λύση για μια φορητή συσκευή. Το τελικό του μέγεθος είναι 92 KB, ακριβώς κάτω από το όριο των 100 KB. Εκεί που το πρόγραμμα αποτυγχάνει είναι στο ότι είναι μόνο αρμόδιο για την αποστολή δεδομένων και δεν παρέχει οποιαδήποτε μέσο για την αλληλεπίδραση με τα δεδομένα μετά από αίτημα του χρήστη. Δεν έχει επίσης καμία ιδιαίτερη διεπαφή ώστε να αλληλεπιδρά με άλλους server του ίδιου τύπου σε ένα περιβάλλον όπου διάφοροι αισθητήρες με μια ενσωματωμένη λύση μServer είναι διαθέσιμοι. Αυτή η περιορισμένη λειτουργία φυσικά δεν μικραίνει την αξία του ως συμπαγές και αποδοτικό πρόγραμμα κάτω από ορισμένες συνθήκες. Παρουσιάζει πολύ μικρή κατανάλωση μνήμης και ελάχιστη χρήση της CPU καθιστώντας τον ιδανικό για τις συσκευές φτωχές σε πόρους. Ο κώδικας είναι πολύ εύκολο να συντηρηθεί και μπορεί εύκολα να αναβαθμιστεί για να δώσει επιπλέον λειτουργικότητα. Θα μπορούσε να θεωρηθεί ως βασική πλατφόρμα στην οποία κάποιος μπορεί να στηριχτεί προκειμένου να δημιουργηθεί μια προσαρμοσμένη λύση ανάλογα με τις ιδιαίτερες ανάγκες του.

6. ΔΟΚΙΜΗ

Διάφορες δοκιμές πραγματοποιήθηκαν κατά την διάρκεια αυτής της εργασίας. Πολύτιμα στοιχεία εξάχθηκαν κυρίως από τις πιο πρόσφατες δοκιμές όταν ήταν το μServer ήταν στην τελική του μορφή. Στο σύστημα δοκιμής απέδειχθηκε ότι χρησιμοποιεί 1540 Κ μνήμης σε κατάσταση αναμονής. Αυτή η τιμή αυξήθηκε ανάλογα με το μέγεθος του αρχείου που φορτώθηκε στον buffer κάθε φορά που υποβάλλονταν μια αίτηση από ένα client. Κανένα πρόβλημα δεν επισημάνθηκε στη συμπεριφορά του κατά τη διάρκεια όλων των δοκιμών.

5.2.1.3 μServer.h

Το μServer.h είναι το αρχείο δηλώσεων που χρησιμοποιείται σε αυτό το πρόγραμμα τα περιεχόμενα του είναι τα παρακάτω:


#ifndef __μSERVER_H
#define __μSERVER_H

#include
#include

using namespace std;

// Prototypes.

int Routine();
SOCKET ListeningSocket();
void AcceptConnections(SOCKET listening_socket);
bool ReadText( char* filename, char* buffer );
DWORD WINAPI Session(void* sock);

#endif

5.2.1.2 μServer.cpp

Αυτό είναι το αρχείο στο οποίο βρίσκεται το σημαντικότερο μέρος του κώδικα και φιλοξενεί τις λειτουργίες ListeningSocket, AcceptConnections, Session, ReadText και Routine. Η λειτουργία Routine είναι η λειτουργία που οδηγεί το πρόγραμμα κάνοντας κλήσεις στην AcceptConnections και ListeningSocket και θέτοντας σε κίνηση το όλο πρόγραμμα, αλλά δεν είναι μεγάλου ενδιαφέροντος όσο αφορά τη μελέτη του μServer.
Η πρώτη λειτουργία που θα εξηγήσουμε είναι η ListeningSocket. Αυτή είναι αρμόδια για την προετοιμασία ενός χώρου μνήμης για τα δεδομένα του socket και τη δημιουργία ενός Listening Socket. Κατά χρησιμοποίηση IPv4, της τρέχουσας έκδοσης του πρωτοκόλλου IP ο server παίρνει μια διεύθυνση IP που αντιπροσωπεύεται από μια 32-bit ποσότητα. Για να επικοινωνήσει ένας client μέσω του TCP αυτή η διεύθυνση πρέπει να οριστεί όπως επίσης και η θύρα την οποία χρησιμοποιεί ο server. Στο WINSOCK αυτό γίνεται με τη χρήση μιας δομής αποκαλούμενης SOCKADDR_IN που προετοιμάζει την μνήμη που χρησιμοποιεί το socket.

sockaddr_in servaddr;
servaddr. sin_family = AF_INET ;
servaddr. sin_port = htons (7000);
servaddr. sin_addr. s_addr = htonl ( INADDR_ANY);

Μπορεί κάποιος να παρατηρήσει τρία διαφορετικά πεδία που εμπλέκονται στην διαδικασία. Το πεδίο family προσδιορίζει ότι χρησιμοποιούμε την οικογένεια διευθύνσεων IP, το πεδίο port καθορίζει τη θύρα επικοινωνίας TCP (σε αυτήν την περίπτωση καθορίζεται να είναι 7000) και το πεδίο sin_addr χρησιμοποιείται για την αποθήκευση της διεύθυνσης IP ως ποσότητα τεσσάρων bytes (μη προσημασμένος μεγάλος ακέραιος αριθμός).
Αφού ετοιμάσουμε τον χώρο μνήμης του socket προχωρούμε στην ListeningSocket για να δημιουργήσουμε ένα Listening Socket χρησιμοποιώντας την μνήμη με κάποιο έλεγχο λάθων.
SOCKET listening_socket = 0;

listening_socket = socket(AF_INET, SOCK_STREAM, 0);
if (listening_socket == INVALID_SOCKET)
{
cerr << "Socket creation failed" << endl;
}
else
if (bind(listening_socket, (sockaddr *)&servaddr, sizeof(servaddr)) == SOCKET_ERROR)
{
cerr << "Socket creation failed with " << WSAGetLastError() << endl;
}

Ένας Listening Socket αποκαλούμενος listening_socket ορίζεται και παίρνει τις τιμές που περιγράφηκαν παραπάνω. Η λειτουργία bind μόλις δημιουργηθεί συσχετίζει το socket με μια διεύθυνση προκειμένου να δημιουργηθεί ένα κανάλι επικοινωνίας. Κατόπιν γίνεται ένας έλεγχος για να εξασφαλίσουμε ότι το socket δημιουργήθηκε κανονικά. Και μετά άλλος ένας για να αποφύγουμε άλλο ένα πιθανό σφάλμα κατά την διαδικασία. Η δομή WSAGetLastError επιστρέφει ένα κωδικό λάθους, εάν κάποιος έχει εμφανιστεί, που προσδιορίζει την πηγή του προβλήματος.
Ένα από τα πιο σημαντικά μέρη της λειτουργίας AcceptConnections θα παρουσιαστούν για να δείξουμε πώς λειτουργεί και ποιος είναι ο ρόλος της στο πρόγραμμα. Η αποδοχή των συνδέσεων είναι το μέρος όπου επιτυγχάνεται η επικοινωνία με τον client και πραγματοποιείται χρησιμοποιώντας τη λειτουργία του API Accept. Η Accept δέχεται ένα σύνολο παραμέτρων που ορίζουν ένα Accepting Socket. Η πρώτη παράμετρος είναι ο δεσμευμένος socket σε κατάσταση Listening η οποία είναι η διεπαφή μέσα από την οποία ο client επικοινωνεί με τον μServer. Ακολουθεί η διεύθυνση μιας έγκυρης δομής SOCKADDR_IN και οι επόμενες δύο παράμετροι ορίζουν το μήκος της δομής. Η Accept επιστρέφει ένα νέο socket descriptor που είναι τώρα η σύνδεση με τον client.
client_socket = accept(server_socket, (sockaddr *) &cliaddr, &clilen);

Ακολουθεί ξανά κάποιος έλεγχος σφάλματος για να εξασφαλιστεί ότι όλα πήγαν καλά. Πρέπει να σημειωθεί σε αυτό το σημείο ότι αφού ο client έχει γίνει αποδεκτός τώρα χρησιμοποιώντας το νέο socket, ο listening socket είναι πάλι διαθέσιμος και περιμένει νέες εισερχόμενες κλήσεις. Κατόπιν η λειτουργία προχωρά στη δημιουργία ενός thread που θα ανατεθεί στον client. Η μέθοδος της χρήσης thread με blocking sockets υιοθετήθηκε δεδομένου ότι τα threads υποστηρίζονται από τα Windows CE και είναι μια πολύ αποδοτική λύση για μικρής κλίμακας server όπου η πολυπλοκότητα του προγράμματος δεν αυξάνεται υπερβολικά από τη χρήση τους. Ένας άλλος λόγος είναι ο περιορισμός των blocking sockets: ένα blocking socket δεν θα επιστρέψει έως ότου τελειώσει το έργο του ή αποτύχει. Εάν τίποτα από αυτά δεν συμβεί, το socket δεν επιστρέφει ποτέ και ο server παύει να λειτουργεί, ανίκανος να εκτελέσει άλλες εργασίες. Εάν ορίζεται ένα thread σε κάθε client έπειτα ένα άλλο thread μπορεί να ικανοποιήσει το επόμενο αίτημα χωρίς την καθυστέρηση του μServer.
Κάθε thread κάνει μια κλήση στη λειτουργία Session η οποία στέλνει στον client τα περιεχόμενα που ζητά.

DWORD nThreadID;
CreateThread(0, 0, Session, (void*)client_socket, 0, &nThreadID);

Η Session προκειμένου να επιτευχθεί αυτό κάνει μια δεύτερη κλήση στη λειτουργία ReadText για να διαβάσει τα περιεχόμενα.

bool ReadText( char* filename, char* buffer )
{
FILE *fp;
char temp[4096] = {0};

fp = fopen( filename, "r+" );
if( fp == NULL ) {
return false;
}

fgets( temp, sizeof(temp), fp);


int a= strlen(temp);
memcpy(buffer, temp, strlen(temp)+1);
return true;
}

Όπως μπορούμε να δούμε η ReadText είναι αρκετά απλή. Αυτό που κάνει βασικά είναι να φορτώσει τα περιεχόμενα του αρχείου που αντιπροσωπεύει τα δεδομένα του αισθητήρα σε μια προσωρινή περιοχή που βρίσκεται στην τοπική μνήμη του server. Η Fopen ανοίγει το αρχείο και η memcpy το φορτώνει στη μνήμη.
Πίσω στη λειτουργία session αυτό που συμβαίνει αφού έχει γίνει η κλήση στην ReadText είναι να δημιουργήσει μια προσωρινή περιοχή, να την φορτώσει με τα περιεχόμενα και έπειτα να χρησιμοποιήσει την λειτουργία send του WINSOCK API για να τα διαβιβάσει στον client.
SOCKET clientsocket = (SOCKET)sock;

char filename[] = "./hello.txt";
char buffer[1024];
memset(buffer, 1024, 1);

// Reading content to send

ReadText(filename, buffer);

// Trying to send

int bytes = send(clientsocket, buffer, strlen(buffer), 0);
if (bytes > 0)
{
cout << "Bytes sent == " << bytes << endl;

}
else
if (bytes == SOCKET_ERROR)
{
return false;
}

Eειδικότερα πρόκειται να δώσουμε προσοχή στο μέρος όπου πραγματοποιείται η μετάδοση. Αυτό γίνεται στην ακόλουθη γραμμή:
int bytes = send(clientsocket, buffer, strlen(buffer), 0);


H Send είναι μια λειτουργία του WINSOCK API που ορίζεται ακριβώς για τη μετάδοση. Η πρώτη παράμετρος είναι μια παράμετρος socket που αντιπροσωπεύει το ήδη συνδεδεμένο socket για να στείλει τα δεδομένα. Αυτό αντιπροσωπεύεται από το clientsocket. Η δεύτερη παράμετρος είναι ένας δείκτης σε έναν character buffer, που εμπεριέχει αυτά τα δεδομένα και αντιπροσωπεύεται από το buffer. Η τρίτη παράμετρος, strlen, προσδιορίζει τον αριθμό των χαρακτήρων στο buffer και η τελευταία, που καλείται παράμετρος flag μπορεί να έχει διάφορες τιμές αλλά στην περίπτωσή μας έχει τιμή 0. Μια άλλη πιθανή παράμετρος είναι η MSG_DONTROUTE η οποία θα μπορούσε να απαιτήσει από το πρωτόκολλο μεταφορέα, παραδείγματος χάριν το πρωτόκολλο TCP, να μην αναδρομολογήσει τα δεδομένα που στάλθηκαν.

5.2.1.1 Main.cpp

Το αρχείο main.cpp εμπεριέχει την λειτουργία main που όπως περιγράφεται στη διαδικασία σχεδιασμού κάνει τις κλήσεις στη λειτουργία Routine που βρίσκεται στο αρχείο μServer.cpp. Ένα από τα πρώτα πράγματα που κάνει η λειτουργία main είναι να ξεκινήσει το WINSOCK API και έπειτα να κάνει την προαναφερθήσα κλήση στην λειτουργία Routine. Το ξεκίνημα του WINSOCK API γίνεται όπως παρουσιάζεται παρακάτω:

// Create version identifier.

WORD wVersionRequested = MAKEWORD(2,0);

//Start up WINDOWS sockets.

int Ret;
WSADATA wsaData;
if ((Ret = WSAStartup(MAKEWORD(2,0), &wsaData)) != 0)
{

// NOTE: Since Winsock failed to load we cannot use
// WSAGetLastError to determine the specific error for
// why it failed. Instead we can rely on the return
// status of WSAStartup.

printf("WSAStartup failed with error %d\n", Ret);
return 0;
}


Αυτή είναι λίγο πολύ μια τυποποιημένη διαδικασία. Το προσδιοριστικό της έκδοσης δείχνει την έκδοση του API που χρησιμοποιούμε και η WSAStartup φροντίζει για τα υπόλοιπα . Αυτό που ακολουθεί είναι βασικά κάποια routine ελέγχου λαθών σε περίπτωση που κάτι πάει στραβά και το ξεκίνημα αποτύχει. Το τελευταίο τμήμα του κώδικα χρησιμοποιεί την WSACleanup για να αποδεσμεύσει τους πόρους που δεσμεύθηκαν από το winsock και τερματίζει οποιεσδήποτε εκκρεμείς κλήσεις WINSOCK που έχουν γίνει από την εφαρμογή.

if (WSACleanup() == SOCKET_ERROR)
{
printf("WSACleanup failed with error %d\n",WSAGetLastError());
}

5.2.1 ΑΡΧΕΙΑ ΤΟΥ ΠΡΟΓΡΑΜΜΑΤΟΣ ΚΑΙ ΛΕΙΤΟΥΡΓΙΕΣ

Αυτή η παράγραφος παρουσιάζει το περιεχόμενο των αρχείων του προγράμματος περιλαμβάνοντας τον κώδικα και εξηγεί τις λειτουργίες που περιλαμβάνονται σε εκείνα τα αρχεία. Η συνοπτική περιγραφή των σημαντικών τμημάτων πηγαίου κώδικα εξηγείται με σκοπό την ενίσχυση της κατανόησης του αναγνώστη αυτής της μελέτης και τη διευκόλυνση της μελλοντικής ανάπτυξης εργασιών βασισμένες σε αυτό.

5.2 ΕΦΑΡΜΟΓΗ

Κατά την φάση της υλοποίησης αυτής της εργασίας δημιουργήθηκε ένα πρόγραμμα ικανοποιώντας τις απαιτήσεις και τις προδιαγραφές που περιγράφηκαν στο σχετικό κεφάλαιο. Η διαδικασία της ανάπτυξης του πηγαίου κώδικα βασίστηκε στο σχέδιο που δημιουργήθηκε, για να ικανοποιήσει την αναμενόμενη συμπεριφορά του κατά το χρόνο εκτέλεσης του προγράμματος. Το ολοκληρωμένο περιβάλλον ανάπτυξης (IDE) που χρησιμοποιήθηκε ήταν το Microsoft Visual Studio .NET 2003 με τη βιβλιοθήκη MSDN Library 2003 σε πλατφόρμα windows 2003 server. Ο ηλεκτρονικός υπολογιστής που χρησιμοποιήθηκε κατά τη διάρκεια αυτής της εργασίας ήταν ένα AMD Athlon GHz XP 2000 + 1,67GHz με 768 ΜΒ RAM μαζί με άλλες δύο μηχανές δοκιμής με παρόμοιες δυνατότητες που συνδέθηκαν σε ένα μικρό τοπικό δίκτυο (LAN). Ο πηγαίος κώδικας είναι γραμμένος σε τρία διαφορετικά αρχεία: main.cpp, μServer.cpp και μServer.h. Χρησιμοποιεί επίσης ένα εξωτερικό αρχείο με όνομα Hello.txt, το οποίο μαζί με τα προηγούμενα τρία αρχεία, διαμορφώνει το κυρίος σώμα τις εργασίας.

5.1.2.6 MAIN

Η λειτουργία Main είναι η λειτουργία υψηλότερου επιπέδου του μServer αρμόδια για την έναρξη ολόκληρου του συστήματος και την κλήση της λειτουργίας Routine . Εκεί γίνεται η εκκίνηση του WINDOWS Socket API και είναι επίσης αρμόδια για τo ομαλό κλείσιμο του προγράμματος.



Διάγραμμα 7. Οι λειτουργίες του μServer και πως συσχετίζονται .

5.1.2.5 Routine

Η λειτουργία routine είναι η συνάρτηση που οδηγεί τον μServer, αυτή που φροντίζει την κύρια ροή δεδομένων του προγράμματος με την παραγωγή των κλήσεων σε λειτουργίες υψηλοτέρου επιπέδου. Είναι αρμόδια για την κλήση της ListeningSocket για να δημιουργήσει ένα listenig socket, να το δεσμεύει με μια κλήση στη λειτουργία AcceptConnections και να δημιουργήσει το thread μέσω του για θα εξυπηρετήσει κάθε εισερχόμενο client. Η ίδια καλείται από την λειτουργία main του προγράμματος.



Διάγραμμα 6. Η λειτουργία routine κάνοντας κλήσεις στην ListeningSocket και στην AcceptConnections. Η λειτουργία που οδηγεί το πρόγραμμα.

5.1.2.4 ReadText

H ReadText είναι η τελευταία λειτουργία σε μια σειρά από κλήσεις. Έχει σαν σκοπό να διαβάσει τα περιεχόμενα του αρχείου που αντιπροσωπεύει τα δεδομένα του αισθητήρα προς το μServer και να τα φορτώσει σε μια προσωρινή περιοχή στη μνήμη του συστήματος.

5.1.2.3 Session

Η λειτουργία session είναι υπεύθυνη για τη φροντίδα της συναλλαγής με έναν client, κάθε φορά που καλείται. Διαβάζει τα στοιχεία που φορτώνονται στη μνήμη του server και τα στέλνει στον client μέσω του thread που δημιουργείται από τη λειτουργία AcceptConnections. Η session για να ολοκληρώσει το έργο της κάνει μια κλήση στη λειτουργία ReadText.



Διάγραμμα 5. Η λειτουργία session κάνει μια κλήση στη λειτουργία ReadText.

5.1.2.2 AcceptConnections

Αυτή η λειτουργία είναι αρμόδια για το χειρισμό του listening socket και την αποδοχή της σύνδεσης που επιχειρείται από έναν client. Προχωρά στη δημιουργία ενός thread για να εξυπηρετήσει τον κάθε εισερχόμενο client και κάνει μια κλήση σε μια άλλη λειτουργία, session, η οποία είναι αρμόδια για τη διαβίβαση των δεδομένων στον client.



Διάγραμμα 4. Η συνάρτηση AcceptConnections κάνει μια κλήση στη λειτουργία Session.

5.1.2.1 ListeningSocket

Η λειτουργία ListeningSocket φροντίζει για τη δημιουργία ενός listening socket στην πλευρά του μServer. Εκεί είναι όπου ο μServer θα ξεκινήσει να περιμένει εισερχόμενες συνδέσεις. Καλείται ListeningSocket επειδή η λειτουργία μοιάζει με κάποιον που περιμένει να ακούσει μια κλήση όπως κάνει ο μServer για έναν client.

5.1.2 ΔΙΑΓΡΑΜΜΑΤΑ ΛΕΙΤΟΥΡΓΙΑΣ

Τα διαγράμματα λειτουργίας προσφέρουν μια πιο λεπτομερή θεώρηση της συμπεριφοράς κατά το χρόνο εκτέλεσης του προγράμματος. Οδηγεί το θεωρητικό σχεδιασμό ένα βήμα προς τα εμπρός στο επίπεδο του κώδικα και προετοιμάζει τη διαδικασία για το γράψιμο κώδικα έτσι ώστε να εφαρμοστεί η λύση.

5.1.1 ΣΥΜΠΕΡΙΦΟΡΑ ΚΑΤΑ ΤΟΝ ΧΡΟΝΟ ΕΚΤΕΛΕΣΗΣ

Μόλις ο μServer αρχίσει να λειτουργεί στο σύστημα που εγκαταστάθηκε περιμένει αιτήματα σύνδεσης από τους clients. Το πρόγραμμα ανοίγει ένα socket τύπου listening που περιμένει για να λάβει εισερχόμενες αιτήσεις και να τις δεσμεύσει λίγο πολύ όπως εξηγούνται στις προδιαγραφές ενός βασικού TCP server στο κεφάλαιο "ΑΠΑΙΤΗΣΕΙΣ ΚΑΙ ΠΡΟΔΙΑΓΡΑΦΕΣ".
Μια προσπάθεια σύνδεσης στο μServer από τον client θα μπορούσε να έχει σαν αποτέλεσμα μια αποτυχία εάν ο server λειτουργεί στο μέγιστο των δυνατοτήτων του, κοπεί η σύνδεση ή τεθεί ένα εσφαλμένο αίτημα από τον client. Παραδείγματος χάριν μια προσπάθεια σύνδεσης στη διεύθυνση IP του server αλλά σε μια διαφορετική θύρα από την προκαθορισμένη στην προδιαγραφή του listening socket descriptor, θα έπαιρνε απάντηση ένα μήνυμα που θα δήλωνε ότι η σύνδεση σε αυτή τη θύρα απέτυχε.



Εικόνα 1. Αποτυχία σύνδεσης λόγω του λανθασμένης θύρας

Μόλις τεθούν οι κατάλληλες τιμές από τον client και ο server είναι διαθέσιμος, η σύνδεση πρέπει να δημιουργηθεί κανονικά.



Εικόνα 2. περιμένοντας για συνδέσεις



Εικόνα 3. δημιουργία σύνδεσης

Όπως φαίνεται στην εικόνα 3 που ο μServer έχει αρχικοποιηθεί, έχει δημιουργήσει ένα listening socket και δέχτηκε ένα επιτυχές αίτημα για σύνδεση αναγνωρίζοντας τη διεύθυνση IP και τη θύρα του client. Σε αυτό το σημείο ο μServer θα ξεκινήσει να διαβάζει ένα αρχείο το οποίο αντιπροσωπεύει δεδομένα που συγκεντρωθήκαν από τον (τους) αισθητήρα (αισθητήρες) και θα προσπαθήσει να τα μεταδώσει στον client. Ένα αρχείο που ονομάζεται "Hello.txt" έχει δημιουργηθεί για να αντιπροσωπεύει τα δεδομένα των αισθητήρων και έχει αποθηκευτεί τοπικά στη μηχανή δοκιμής. Μόλις φορτωθεί το περιεχόμενο του αρχείου στη μνήμη του συστήματος θα αποσταλεί στη συνέχεια στον client.



εικόνα 4. O server έχει στείλει τa περιεχόμενa του αρχείου και έχει αναγνωρίσει τον αριθμό των bytes που στάλθηκαν. Ο client διαβάζει το περιεχόμενο.

Η εικόνα 4 εκθέτει τα ανωτέρω παρουσιάζοντας την κονσόλα του μServer και την κονσόλα ενός client που επικοινωνεί μαζί του. Ο μServer έχει αποδεχτεί την σύνδεση, έχει διαβάσει τα περιεχόμενα του αρχείου και τα έχει στείλει στον client για ανάγνωση. Ολόκληρη η διαδικασία μπορεί να αντιπροσωπευθεί διαγραμματικά όπως στο παρακάτω διάγραμμα 2.



Διάγραμμα 2. Το μοντέλο μServer

Μια άλλη πτυχή αυτής της διαδικασίας είναι ότι κάθε client κατά την σύνδεση πρόκειται να αντιμετωπιστεί από ένα ξεχωριστό thread έτσι ώστε παράλληλες συνδέσεις να μπορούν να αντιμετωπιστούν από τον server δεδομένου ότι χρησιμοποιεί τις blocking sockets για να επεξεργαστεί κάθε αίτημα. Το διάγραμμα 3 παρέχει μια σχηματική αναπαράσταση αυτού.



Διάγραμμα 3. Αναπαράσταση των threads.

Eάν για οποιοδήποτε αιτία η συνδιαλλαγή αποτύχει, αυτό θα αναγνωριστεί από τον μServer, αλλά δεν θα προσπαθήσει να τερματίσει τη συναλλαγή με τον client. Αυτό γίνεται έτσι ώστε μην κρατηθεί ενεργό το thread και να μην κινδυνεύσει η λειτουργία του, δεδομένου ότι κάθε thread χρησιμοποιεί ένα μέρος της μνήμης έως ότου τερματιστεί. Ένα νέο αίτημα θα πρέπει να υποβληθεί από τον client για να αναδημιουργήσει τη σύνδεση.

5.1 ΑΡΧΙΤΕΚΤΟΝΙΚΗ

Η αρχιτεκτονική του προγράμματος είναι ο σχεδιασμός υψηλού επιπέδου που εξετάζει τη συμπεριφορά του κατά τον χρόνο εκτέλεσης. Η συμπεριφορά κατά τον χρόνο εκτέλεσης επιδεικνύει, κατά την διάρκεια της λειτουργίας του προγράμματος στο προορισμένο περιβάλλον του, πώς υποτίθεται ότι συμβαίνουν τα πράγματα, πώς πραγματοποιείται η ροή των δεδομένων, και ποια είναι η επιθυμητή έκβαση της διαδικασίας.

5. ΣΧΕΔΙΑΣΜΟΣ ΚΑΙ ΥΛΟΠΟΙΗΣΗ

Αυτό το κεφάλαιο εξετάζει τα θέματα σχεδιασμού κι υλοποιήσης. Στο προηγούμενο κεφάλαιο, "ΑΠΑΙΤΗΣΕΙΣ ΚΑΙ ΠΡΟΔΙΑΓΡΑΦΕΣ", περιγράφηκαν τα θέματα των λειτουργιών που περιλήφθηκαν στο πρόγραμμα και οδηγίες αναφορικά για το πώς θα υλοποιήσουμε αυτούς τους στόχους. Τώρα ακολουθεί μια προσπάθεια να αναπαραστήσουμε ξεκάθαρα την διαδικασία ανάπτυξης και να τεθεί η θεωρία σε πράξη. Η αρχιτεκτονική του προγράμματος, τεχνικές κώδικα και ο πηγαίος κώδικας πρόκειται να συζητηθούν και να μελετηθούν για να αποδώσουν μια λεπτομερή κατανόηση της συμπεριφοράς και της λειτουργίας του προγράμματος στον αναγνώστη.

4.3.5 ΤΕΧΝΙΚΕΣ - ΣΥΝΕΧΕΙΑ

Πολλά άλλα ζητήματα πρέπει να ληφθούν υπόψη κατά τον σχεδιασμό ενός προγράμματος client-server. ¶Η συμβατότητα πρωτοκόλλων είναι ένα από αυτά. Όπως είναι ¶γνωστό το βασικό πρωτόκολλο πίσω από οποιοδήποτε δίκτυο, είναι το IP που είναι σε αυτήν την περίοδο στην έκτη έκδοσή του, αλλά η προηγούμενη τέταρτη έκδοση υποστηρίζεται από μεγάλη πλειοψηφία δικτύων. Ένας σχεδιαστής server πρέπει να σκεφτεί το κατά πόσον είναι απαραίτητο να αντιμετωπίσει αυτό το ζήτημα.

Ενα άλλο σημαντικότερο ζήτημα είναι ο επιτρεπόμενος αριθμός συνδέσεων κάθε φορά. Αυτό το ζήτημα συσχετίζεται τυπικά με το hardware του μηχανήματος όπως για παράδειγμα είναι η φυσική μνήμη του server ή το διαθέσιμο εύρος ζώνης. Περαιτέρω πάνω σε αυτό, είναι επιτακτικό να συζητηθούν τακτικές προσωρινής μνήμης (bufffering) προκειμένου να αντιμετωπίσουμε επιπλέον αιτήματα για υπηρεσία. Αυτό το ζήτημα αναφέρεται γενικά ως server hardening.

Για να αντιμετωπίσουμε τυχόν αποτυχίες του server θα πρέπει να συμπεριλάβουμε συναρτήσεις διαχείρισης σφαλμάτων. Ανάλογα με πόσο κρίσιμη είναι η λειτουργία της εφαρμογής, αυτές οι συναρτήσεις γίνονται όλο και πιο σημαντικές και οι εκτιμήσεις του είδους πρέπει πάντα να λαμβάνουν υπόψη εάν το πρόγραμμα πρόκειται να λειτουργήσει με κάποια αξιοπιστία.

4.3.4 ΤΕΧΝΙΚΕΣ – ΧΕΙΡΙΣΜΟΣ ΤΟΥ TCP ΣΕ ΒΑΣΙΚΕΣ ΕΦΑΡΜΟΓΕΣ SERVER

Τα απαραίτητα βήματα για μια βασική ή οποιαδήποτε άλλη εφαρμογή server είναι παρόμοια σε γενικές γραμμές με εκείνα των παραπάνω παραγράφων. ¶Αυτό προέρχεται πάλι από τις λειτουργίες του πρωτοκόλλου TCP. ¶

Δημιουργία ΕΝΟΣ TCP SOCKET ¶

Η διαδικασία για τη δημιουργία ενός TCP socket για ένα πρόγραμμα server είναι ίδια με αυτή που απαιτείται για ένα ισοδύναμο πρόγραμμα client.

¶

ΔΕΣΜΕΥΟΝΤΑΣ ΜΙΑ ΘΥΡΑ ΤΟΥ SERVER ΣΕ ένα SOCKET ¶

Καλώντας την διαδικασία bind και συμπληρώνοντας μια διεύθυνση δομή τύπου διεύθυνσης internet socket η θύρα του server δεσμεύεται.. ¶Αυτό παρέχει στην ουσία ένα σημείο αναφοράς για τα προγράμματα client και για το πρωτόκολλο TCP έτσι ώστε να δημιουργήσουν μια σύνδεση με τον server.

¶Μετατρoπη σε listening socket¶

Παρέχοντας στον server ένα socket δεν είναι αρκετό για το πρόγραμμά μας εάν θέλουμε να λειτουργήσει σωστά. Προσδιορίζοντας ότι το socket πρόκειται να είναι τύπου listening επιτυγχάνουμε την αφύπνιση του server για αιτήσεις υπηρεσίας από κλήσεις των cllent και την αποδοχή εισερχομένων συνδέσεων. ¶Για να επιτύχουμε τη μετατροπή, καλούμε την διαδικασία listen. ¶Αυτά τα τρία βασικά βήματα που περιγράφησαν μέχρι τώρα, socket, bind και listen προετοιμάζουν αυτό που αποκαλείται γενικά ως listening descriptor. ¶

Αποδοχή ΤΗΣ σύνδεσης και απάντηση ¶

Κάτω από κανονικές συνθήκες, ο server είναι "κοιμισμένος" (ανενεργός) περιμένοντας ένα client να υποβάλει κάποια αίτηση για σύνδεση και να αποδεχτεί το αίτημα. ¶Όταν το TCP "handshake" φθάσει στην ολοκλήρωσή του, επιστρέφεται μια τιμή γνωστή ως connected descriptor. Για κάθε client που συνδέεται στο server επιστρέφεται ένας connected descriptor. ¶ ¶Μετά από αυτό η συνάρτηση Main του προγράμματος παρέχει στον client το ζητούμενο, την υπηρεσία.

¶

ΤΕΡΜΑΤΙΣΜΟΣ SERVER

Καλώντας την διαδικασία close ο server τερματίζει την σύνδεση με τον client. ¶Αυτό δεν σημαίνει φυσικά ότι το πρόγραμμα server τερματίζεται αλλά μόνο η συγκεκριμένη σύνδεση.

4.3.3 ΤΕΧΝΙΚΕΣ - ΧΕΙΡΙΣΜΟΣ ΤΟΥ TCP ΣΕ ΒΑΣΙΚΕΣ ΕΦΑΡΜΟΓΕΣ CLIENT

Κατά δημιουργία μιας δικτυακής εφαρμογής σε C++, η πιο κρίσιμη κλάση
είναι φυσικά η κλάση main η οποία περιγράφει βασικά τις μεθόδους που
χρησιμοποιούνται για την υλοποίηση του στόχου της εφαρμογής. Ανεξάρτητα
- 28 -
από αυτό, σχεδόν κάθε δικτυακή εφαρμογή που χρησιμοποιεί το πρωτόκολλο
TCP ενσωματώνει μερικές κοινές διαδικασίες. Αυτές οι διαδικασίες προέρχονται
ασφαλώς από τις λειτουργίες το ίδιου του πρωτοκόλλου. Το σημαντικότερο είναι
ότι από τη πιο βασική έως την πιο περίπλοκη εφαρμογή παραμένουν σχεδόν οι
ίδιες διαδικασίες.
Λαμβάνοντας αυτό υπόψη καθώς επίσης και τα ανωτέρω, όσον αφορά την
το πρωτόκολλο TCP, τα ακόλουθα βήματα μπορούν να προσδιοριστούν:
INCLUDE HEADERS
Οι περισσότερες δικτυακές εφαρμογές χρειάζονται ένα σύνολο από
system headers για να καθορίσουν τις σταθερές που χρησιμοποιούνται από το
πρόγραμμα.
ΔΗΜΙΟΥΡΓΙΑ ΤΟΥ TCP SOCKET
O όρος socket χρησιμοποιείται σε πολλές διαφορετικές περιπτώσεις. Σε
αυτό το πλαίσιο αναφερόμαστε σε ένα TCP socket το οποίο είναι συνώνυμο με
ένα σημείο τερματισμού του TCP. Βασικά όταν εισάγουμε ένα TCP socket στον
κώδικά μας καθορίζουμε ένα αρχικό σημείο για μια κλήση σύνδεσης TCP που θα
ακολουθήσει. Το οποίο μας οδηγεί στο επόμενο βήμα: ο καθορισμός του προς τα
που πρόκειται να γίνει η σύνδεση.
ΚΑΘΟΡΙΣΜΟΣ ΤΗΣ ΔΙΕΥΘΥΝΣΗΣ IP ΚΑΙ ΤΗΣ ΘΥΡΑΣ ΤΟΥ SERVER
Σε αυτό το βήμα το πρόγραμμά μας παρέχει τις απαραίτητες πληροφορίες
στο socket API, μια δομή διεύθυνσης internet socket που περιέχει τη διεύθυνση
IP και τη θύρα του server. Κατάλληλες στην εφαρμογή μας γνωστές θύρες
πρόκειται να εξεταστούν. Επίσης με τη χρήση κατάλληλων βιβλιοθηκών
συναρτήσεων μετατρέπουμε τα ορίσματα μας στην κατάλληλη μορφή.
- 29 -
ΔΗΜΙΟΥΡΓΙΑ ΤΗΣ ΣΥΝΔΕΣΗΣ SERVER
Η συνάρτηση connect, όπως χρησιμοποιείται με τα TCP sockets,
αναλαμβάνει το έργο της δημιουργίας μιας σύνδεσης TCP με το server που
προσδιορίζεται στα προηγούμενα βήματα .
ΤΕΡΜΑΤΙΣΜΟΣ ΠΡΟΓΡΑΜΜΑΤΟΣ
Παρέχοντας το όρισμα exit το πρόγραμμα τερματίζεται. Περαιτέρω
εντολές πριν από αυτό το σημείο ίσως να είναι απαραίτητες.

4.3.2 ΔΗΜΙΟΥΡΓΙΑ ΚΑΙ ΤΕΡΜΑΤΙΣΜΟΣ ΣΎΝΔΕΣΗΣ TCP

Η βασική έννοια πίσω από την δημιουργία μιας σύνδεσης TCP είναι η
"three way handshake". Μπορούμε να το θεωρήσουμε ανάλογο με ένα
τηλεφωνικό σύστημα [ Nemeth 1997 ] το ακόλουθο σενάριο εμφανίζεται όταν
δημιουργείται μια σύνδεση [ Stevens Ρ., Fenner Β. και Rudoff A.Μ. 2003 ]:
1. Ο server πρέπει να προετοιμαστεί για να δεχτεί μια εισερχόμενη σύνδεση.
Αυτό γίνεται κανονικά με την κλήση των διαδικασιών socket, bind και listen και
καλείται παθητικό άνοιγμα.
2. Ο client δημιουργεί ένα ενεργητικό άνοιγμα καλώντας την διαδικασία
connect. Αυτό αναγκάζει το TCP του client να στείλει ένα πακέτο συγχρονισμού
(SYN), το οποίο δηλώνει στον server τον αρχικό αριθμό ακολουθίας του client για
τα δεδομένα που θα στείλει ο client στη σύνδεση. Κανονικά δεν υπάρχει κανένα
δεδομένο δεν στέλνεται με το πακέτο SYN , απλά περιέχει ακριβώς μια κεφαλίδα
IP, μια κεφαλίδα TCP και πιθανές επιλογές TCP.
2. Ο server θα πρέπει να αναγνωρίσει (ACK) το SYN του client και κατόπιν θα
πρέπει να στείλει επίσης το δικό του πακέτο SYN, το οποίο περιέχει τον αρχικό
αριθμό ακολουθίας για τα δεδομένα που θα στείλει στη σύνδεση. Ο server
στέλνει το δικό του SYN και ACK αναφορικά με το πακέτο SYN του client σε ένα
ενιαίο τμήμα.
3. Ο client πρέπει να αναγνωρίσει το SYN του server.
Όταν πραγματοποιείται ο τερματισμός της σύνδεσης η διαδικασία απαιτεί
ένα επιπλέον πακέτο, ανεβάζοντας τα συνολικά σε τέσσερα [ Stevens Ρ., Fenner
Β. και Rudoff Α.Μ. 2003 ]:
- 27 -
1. Μια εφαρμογή καλεί πρώτα την διαδικασία close, και λέμε ότι αυτό το
άκρο εκτελεί ένα ενεργητικό κλείσιμο. Το TCP αυτού του άκρου στέλνει ένα
πακέτο FIN, το οποίο σημαίνει ότι η εκπομπή δεδομένων τελείωσε.
2. Το άλλο άκρο που λαμβάνει το πακέτο FIN εκτελεί τo παθητικό κλείσιμο.
Το ληφθέν πακέτο FIN αναγνωρίζεται από το TCP. Η λήψη του πακέτου FIN
λαμβάνεται επίσης στην εφαρμογή ως τέλος του αρχείου (μετά από οποιαδήποτε
δεδομένα που μπορεί να είχαν μπει σε κάποια ουρά προς λήψη από την
εφαρμογή), δεδομένου ότι η παραλαβή του πακέτου FIN σημαίνει ότι η
εφαρμογή δεν θα λάβει οποιαδήποτε άλλα πρόσθετα δεδομένα όσον αφορά τη
σύνδεση.
3. Κάποτε αργότερα, η εφαρμογή που έλαβε το τέλος του αρχείου θα κλείσει
το socket της. Αυτό οδηγεί το TCP να στείλει ένα πακέτο FIN.
4. Το TCP στο σύστημα που λαμβάνει αυτό το τελικό πακέτο FIN (το άκρο
που έκανε ενεργητικό κλείσιμο) αναγνωρίζει το πακέτο FIN.
"Δεδομένου ότι ένα πακέτο FIN και ένα πακέτο ACK
απαιτούνται σε κάθε κατεύθυνση, τέσσερα τμήματα
απαιτούνται κανονικά. Χρησιμοποιούμε τον όρο "κανονικά"
επειδή σε μερικά σενάρια το πακέτο FIN στο βήμα 1
στέλνεται μαζί με δεδομένα. Επίσης, τα τμήματα στα βήματα
2 και 3 προέρχονται από το άκρο που πραγματοποιεί το
παθητικό το κλείσιμο και θα μπορούσαν να συνδυαστούν σε
ένα τμήμα."

4.3.1 ΤΟ ΜΟΝΤΕΛΟ ΛΕΙΤΟΥΡΓΊΑΣ ΤΟΥ ΠΡΩΤΟΚΟΛΛΟΥ TCP

Δεδομένου ότι οι προδιαγραφές βρίσκονται στο πρωτόκολλο TCP [ Postel
1981c ] [ Jacobson, Braden και Borman 1992 ] [ Allman, Paxson και Stevens
1999 ] [ Paxson και Allman 2000 ] [ Allman, Floyd και Partridge 2002 ],
αναφορικά με το μοντέλο λειτουργίας του, ο ρόλος του είναι να χειριστεί τις
- 25 -
μεταδόσεις δεδομένων. Βασικά, με την κλήση του πρωτοκόλλου μια διαδικασία
είναι σε θέση να περάσει τμήματα δεδομένων σαν ορίσματα. Το πρωτόκολλο
είναι υπεύθυνο έπειτα για τη συσκευασία των δεδομένων που λαμβάνει, την
τμηματοποίηση τους και με την κλείσει της σχετικής διαδικασίας την διαβίβαση
τους στον παραλήπτη.
Το λαμβάνον TCP συνεχίζει κατόπιν με την αντίθετη λειτουργία της επαν-
αποθήκευσης των δεδομένων από τα ληφθέντα τμήματα και ενημερώνει το
χρήστη. Προκειμένου να εξασφαλιστεί η αξιοπιστία, τμήματα δεδομένων ελέγχου
συρράπτονται μαζί με κάθε διαβιβασθέν τμήμα. Αυτές οι προστιθέμενες
πληροφορίες είναι αρμόδιες για την εξασφάλιση αναμετάδοσης των χαμένων
δεδομένων και τη ταξινόμηση των πακέτων κατά την παραλαβή. Η βάση φυσικά
για αυτό το σχέδιο είναι στην πραγματικότητα η υπόθεση ότι υπάρχει μια
διαδικασία πρωτοκόλλου Διαδικτύου που επιθεωρεί τη χρήση του TCP API. Ο
στόχος αυτής της διεργασίας είναι το πακετάρισμα των τμημάτων μέσα στα
διαγράμματα δεδομένων Διαδικτύου και η δρομολόγηση τους προς τον
προορισμό. Το διάγραμμα δεδομένων έπειτα ενσωματώνεται σε ένα τοπικό
πακέτο δικτύου. Η περαιτέρω συσκευασία ή ο τεμαχισμός είναι πιθανά καθώς το
πακέτο διαβιβάζεται μέσω του Διαδικτύου.
Όταν το διάγραμμα πακέτων δεδομένων Διαδικτύου διέρχεται μέσω μιας
πύλης μεταξύ δικτύων, αποσυσκευάζεται από το τοπικό πακέτο και εξετάζεται
για να προσδιοριστεί ο επόμενος προορισμός του. Όπως αναφέρθηκε πριν, κάθε
πακέτο μπορεί να τεμαχιστεί περαιτέρω κάθε φορά που αναδρομολογείται εάν
αυτό είναι απαραίτητο. Αυτό οφείλεται μεταξύ άλλων λόγων και στην κίνηση του
δικτύου.
Το πρωτόκολλο λαμβάνει υπόψη επίσης τις εκτιμήσεις για το είδος της
υπηρεσίας, για την οποία προορίζεται κάθε διάγραμμα δεδομένων όπως και
ζητήματα ασφάλειας, επιτρέποντας έτσι στους hosts και στις πύλες που
λειτουργούν σε περιβάλλοντα με πολλαπλά επίπεδα ασφάλειας να διαχωρίσουν
τα διαγράμματα δεδομένων, σύμφωνα με τις προδιαγραφές ασφάλειάς τους.

4.3 ΠΡΟΔΙΑΓΡΑΦΕΣ ΣΤΙΣ ΕΦΑΡΜΟΓΕΣ SERVER

Δεδομένου ότι η εφαρμογή microserver πρόκειται να στηριχθεί στο
πρωτόκολλο TCP πρόκειται να μοιραστεί τα χαρακτηριστικά της με άλλες κοινές
εφαρμογές server. Αυτό το τμήμα πρόκειται να εισαγάγει το πρότυπο του
μοντέλο λειτουργίας του χρησιμοποιούμενου πρωτοκόλλου και τις
προγραμματιστικές μεθόδους σχετιζόμενες με τον δικτυακό προγραμματισμό.

4.2.3 ΠΕΡΙΒΑΛΛΟΝ ΕΦΑΡΜΟΓΗΣ ΚΑΙ API

Θεωρούμε ότι σαν περιβάλλον εφαρμογής θα χρησιμοποιηθεί μια έκδοση των
windows, η οποία είναι ικανή να τρέξει σε μια πλατφόρμα με περιορισμένους
πόρους. Παραδείγματος χάριν όπως στην περίπτωση των Jie Liu, Elaine Cheong,
και Feng Zhao [ 2005 ] η πλατφόρμα είναι ένας επεξεργαστής ισοδύναμος με
1GHz Pentium ΙΙΙ με 256MB RAM. Η λύση της Microsoft για ενσωματωμένα
συστήματα είναι η πλατφόρμα WINDOWS CE. Η διαφορά της ανάπτυξης μιας
δικτυακής εφαρμογής σε WINDOWS CE και όχι σε άλλη έκδοση των WINDOWS
έγκειται κυρίως στο γεγονός ότι WINSOCK 2 το πιό πρόσφατο δικτυακό API της
Microsoft δεν υποστηρίζεται και κάποιος θα πρέπει να γράψει κώδικα συμβατό με
WINSOCK 1 - την προηγούμενη έκδοση του WINSOCK. Το WINSOCK είναι ένα
προγραμματιστικό API για δίκτυα, το οποίο έχει πάρει αρκετά στοιχεία από το
BERKELEY socket API (BSD) σε πλατφόρμες Unix. Χρησιμοποιώντας το WINSOCK
ή τα BSD sockets μπορεί κάποιος να έχει πρόσβαση σε ένα πλήθος πρωτοκόλλων
- 24 -
δικτύωσης, αν και έχουμε να κάνουμε με Win32 εφαρμογές το WINSOCK API έχει
εξελιχθεί έτσι ώστε να είναι ανεξάρτητο πρωτοκόλλου [ Anthony J., Ohlund J.
2002 ]. Υπάρχουν πολλοί διαφορετικοί τρόποι να επικοινωνήσει κάποιος με
WINSOCK, όπως blocking sockets, non blocking sockets, ασύγχρονα sockets,
χρησιμοποιώντας την λειτουργία select event objects και overlapped I/O.
Επιπλέον κάθε μια από αυτές τις τεχνικές επικοινωνίας μπορεί να χρησιμοποιηθεί
μαζί με threads. Η επιλογή της χρησιμοποίησης μιας από αυτές τις τεχνικές με
threads ή χωρίς λαμβάνεται σε σχέση με την πλατφόρμα που χρησιμοποιείται και
τη συμπεριφορά που θα πρέπει να καταδείξει ο server. Είναι ένα κρίσιμο σημείο
για το σχέδιο της εφαρμογής, αλλά σε αυτό το σημείο δεν είναι απαραίτητο να
επεκταθούμε στο θέμα δεδομένου ότι θα συζητηθεί αναλυτικότερα στο
σχεδιαστικό μέρος.

4.2.2 ΠΡΩΤΟΚΟΛΛΟ

Το πρωτόκολλο επικοινωνιών που επιλέχθηκε είναι το TCP/IP, εν μέρει για τη δημοτικότητά του και εν μέρει για την αξιοπιστία του. ¶ Η εφαρμογή μιας λύσης βασισμένης στο TCP/IP δημιουργεί αυτόματα κάποια ευκολία χρήσης για τον προγραμματιστή και ένα ελάχιστο αριθμό σφαλμάτων κατά τη διάρκεια της μετάδοσης. ¶Ακόμα κι αν τα λάθη εμφανίζονται, το ίδιο το πρωτόκολλο είναι σε θέση να τα προσδιορίσει στις περισσότερες περιπτώσεις και να αναμεταδώσει το τμήμα που απέτυχε να φθάσει στον προορισμό του. ¶Μερικοί φορές φυσικά, όταν έχουμε να κάνουμε με την ζωντανή ροή δεδομένων από τους αισθητήρες αυτή δεν είναι η βέλτιστη λύση αλλά τουλάχιστον έχουμε μια χαμηλότερη αναλογία απώλειας πακέτων [ Postel J. Β. 1981c ]. ¶Άλλα πρωτόκολλα που στερούνται αυτό το είδος ελέγχου της μετάδοσης πακέτων όπως το UDP, που είναι ένα πρωτόκολλο το οποίο δεν υποστηρίζει σύνδεση, υπό την έννοια ότι μόλις διαβιβαστεί το μήνυμα – χωρίς απαραίτητα να γίνει αποδεκτό – τερματίζει τη σύνδεση μεταξύ του server και του client, είναι λιγότερο αξιόπιστο αλλά πολύ γρηγορότερο σε αντίθεση με το TCP. ¶ Η διαφορά στην ταχύτητα οφείλεται φυσικά στα επιπλέον βήματα που κάνει το TCP έτσι ώστε να ελέγξει εάν όλα τα πακέτα έχουν ληφθεί ή όχι. ¶Το TCP/IP είναι επίσης το πρωτόκολλο που χρησιμοποιείται στις περισσότερες εφαρμογές Διαδικτύου και έχει την καθολική υποστήριξη από τους κατασκευαστές συσκευών και λογισμικού. ¶Ο Anthony J., και Ohlund J. [ 2002 ] τονίζουν ότι η Microsoft θεωρεί το TCP/IP ως το κατεξοχήν πρωτόκολλο για τις περισσότερες εφαρμογές της και παρέχει γρήγορη απόκριση σε κάποιο πιθανό σφάλμα, εάν μια εφαρμογή της χρησιμοποιεί το TCP/IP (WINSOCK).

4.2.1 ΓΛΩΣΣΑ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ

Η γλώσσα προγραμματισμού C++ επιλέχτηκε προκειμένου να ξεπεραστεί το εμπόδιο της χαμηλής διαθεσιμότητας μνήμης, δεδομένου ότι έχει κληρονομήσει τις ιδιαίτερα αποδοτικές τεχνικές διαχείρισης μνήμης από την προκάτοχό της γλώσσα C. ¶Αυτός ο παράγοντας συνέβαλε πολύ για να αποκλείσει άλλες περισσότερο φορητές γλώσσες όπως η JAVA της SUN ή C# της Microsoft. Ιδιαίτερα η χρήση των δεικτών αν και δύσκολη στην εξοικείωση μας παρέχει ένα μεγάλο στρατηγικό πλεονέκτημα στην ανάπτυξη μιας τέτοιας εφαρμογής δεδομένου ότι επιτρέπει τη διαχείριση του συστήματος μνήμης. Από την άλλη πλευρά ¶Απα η JAVA και η C# αν και διαφημίζονται ιδιαίτερα για τη φορητότητά τους, απαιτούν την JAVA VIRTUAL MACHINE (JVM) και το .NET FRAMEWORK για να λειτουργήσουν αντίστοιχα. ¶Και τα δύο αυτά περιβάλλοντα έχουν το μειονέκτημα της απαίτησης ιδιαίτερα αρκετών πόρων. Η C¶Η ++ είναι επίσης μια αντικειμενοστραφής γλώσσα - στην πραγματικότητα η C¶Η ++ είναι η πρώτη αντικειμενοστραφής γλώσσα. ¶Αυτό είναι αρκετά χρήσιμο όταν πρέπει κανείς να αντιμετωπίσει τα προβλήματα τις διαχείρησης του κώδικα και του σχεδιασμού του software. ¶Είναι επίσης μια πολύ ώριμη γλώσσα κατάλληλη για μια μεγάλη ποικιλία από περιβάλλοντα, βασιζόμενα σε windows ή POSIX. ¶Αυτό είναι κάτι που για παράδειγμα δεν μπορεί να υποστηρίξει η C# ενώ ο ίδιος κώδικας σε C¶Η ++ με μια επιπλέον προσπάθεια μπορεί να είναι σε θέση να λειτουργήσει και στα δύο περιβάλλοντα. ¶Μερικά μειονεκτήματα της C¶Η ++ είναι το υψηλό επίπεδο δυσκολίας στην χρήση σε αντίθεση με την JAVA και τη C# και το γεγονός ότι περισσότερος πηγαίος κώδικας πρέπει να γραφτεί μερικές φορές προκειμένου να επιτευχθούν τα ίδια αποτελέσματα. ¶Τελικά η C, και η C++ θεωρούνται από πολλούς ότι κοινή γλώσσα προγραμματισμού των Windows και του WINSOCK API είναι προσανατολισμένο γύρω από τη C και τη C++ δεδομένου ότι είναι βασισμένο στο API του προσανατολισμένου σε C BERKELEY socket API (BSD sockets).

4.2 ΠΡΟΔΙΑΓΡΑΦΕΣ

Ο μServer θα πρέπει να καταδείξει μια συμπεριφορά server προκειμένου να δημιουργήσει μια σύνδεση μεταξύ ενός χρήστη - client - και της πλατφόρμας στην οποία πρόκειται να συνδεθεί. ¶Η δημιουργία της σύνδεσης και η μεταφορά μηνυμάτων είναι η βασική λειτουργία που καταδεικνύεται σε κάθε μοντέλο server.¶ Παραδείγματος χάριν ένας WEB, FTP ή άλλου είδους server. ¶Το κύριο σημείο διαφοροποίησης είναι η διαδικασία που πραγματοποιείται από τη στιγμή που ο client πραγματοποιεί μια αίτηση μέχρι τον τερματισμό της σύνδεσης. ¶Ένας web server θα απαντούσε σε μια αίτηση για υπηρεσία στέλνοντας πίσω μια σελίδα HTML, ενώ ένας FTP server θα άρχιζε τη μετάδοση δεδομένων ενός ήδη αποθηκευμένου αρχείου, το οποίο βρίσκεται τοπικά στην ίδια μηχανή με τον server. O¶OO σκοπός του μServer είναι να εγγυηθεί την μετάδοση του σήματος από έναν αισθητήρα σε έναν client. ¶Με άλλα λόγια ένας μServer διαχωρίζεται από άλλα μοντέλα server μέσω της φύσης των περιεχομένων που παραδίδει και της πηγής αυτών. ¶Μια άλλη σημαντική προδιαγραφή είναι το περιβάλλον στο οποίο λειτουργεί. ¶Όπως δηλώθηκε πριν, ο μServer είναι συνήθως ενσωματωμένος στο ίδιο hardware με τον αισθητήρα ή σε πολύ μικρή απόσταση από αυτόν. ¶Αυτό έχει σαν αποτέλεσμα αρκετούς περιορισμούς στο hardware, όπως τo μικρό μέγεθος μνήμης και επεξεργαστικής ισχύος, καθώς επίσης και χωρητικότητας δίσκου. ¶

4.1 ΑΠΑΙΤΗΣΕΙΣ

Η εργασία αυτή θα πρέπει να μας δώσει μια σειρά λειτουργιών προκειμένου να θεωρηθεί επιτυχής. Ο σκοπός¶Ο σκοπός του λογισμικού είναι να δημιουργήσει μια εφαρμογή ικανή να διαχειριστεί την λήψη των δεδομένων από τους αισθητήρες και μέσα από κάποια διαδικασία επεξεργασίας να αποστείλει αυτά τα δεδομένα σε μια μορφή αποδεκτή από ένα χρήστη, που είχε θέσει προηγουμένως ένα σχετικό αίτημα. ¶Η εφαρμογή θα πρέπει να λειτουργήσει στο ίδιο περιβάλλον όπου είναι τοποθετημένος ο αισθητήρας και να εκμεταλλεύεται τους πόρους που θα μπορούσαν να είναι προσπελάσιμοι σε αυτό το περιβάλλον. ¶Οι χρήστες πρέπει να είναι σε θέση να θέσουν το αίτημα για υπηρεσία από μακριά και τουλάχιστον δύο χρήστες θα πρέπει να είναι σε θέση να δεχτούν τα δεδομένα ταυτόχρονα. ¶Κάποιος βαθμός ανοχής σφαλμάτων θα πρέπει επίσης να καταδειχτεί. ¶Οι εφαρμογές πρέπει επίσης να καταδείξουν κάποια μορφή συμβατότητας και έναν υψηλό βαθμό συνδεσιμότητας. ¶

4. ΑΠΑΙΤΗΣΕΙΣ ΚΑΙ ΠΡΟΔΙΑΓΡΑΦΕΣ

Αυτό το κεφάλαιο περιγράφει την εργασία που έγινε πριν την παραγωγή του πηγαίου κώδικα, αναλύει τις απαιτήσεις και τις προδιαγραφές του προγράμματος, τις όποιες αποφάσεις που πάρθηκαν, λαμβάνοντας υπόψη αυτές τις απαιτήσεις και αναφέρει τις απαραίτητες δεξιότητες που έπρεπε να αποκτηθούν για την αποδοτική εφαρμογή των στόχων αυτής της εργασίας. ¶

3.2 ΠΕΡΙΛΗΨΗ ΒΙΒΛΙΟΓΡΑΦΙΚΗΣ ΕΠΙΣΚΟΠΗΣΗΣ

Έχει καταδειχθεί μέχρι τώρα ότι οι εφαρμογές μServer αξίζουν την προσπάθεια να παραχθούν αναφορικά με τα οφέλη που μπορούν να προσφέρουν σε μια ευρεία ποικιλία προβλημάτων. ¶Ειδικά όταν πρόκειται για τα δίκτυα αισθητήρων, οι μServers φαίνονται απανταχού παρόντες και απαραίτητοι για την ενίσχυση της αποδοτικότητας. ¶Διάφορες έρευνες αποδεικνύουν τα παραπάνω ενώ άλλες συζητούν μεθόδους βελτιστοποίησης των ίδιων των μServers. ¶Αυτές οι μέθοδοι περιλαμβάνουν τη συμπίεση δεδομένων προκειμένου να μειωθεί το μέγεθος μετάδοσης και επομένως την κατανάλωση ενέργειας, την απάλειψη χαρακτηριστικών γνωρισμάτων και συγκεκριμένες αρχιτεκτονικές όπως είναι η Mote Hearding [ Schoellhammer και λοιποί 2004 ] [ Stathopoulos και λοιποί 2006 ]. ¶Πρέπει επίσης να επισημανθεί ότι η πλειοψηφία αυτών των ερευνών διαπραγματεύονται δίκτυα μServers παρά μονάδες. ¶Επιπλέον αυτές οι λύσεις μπορούν να υπάρξουν υπό μορφή μεμονωμένων μηχανών ή ενσωματωμένων σε αισθητήρες και τις περισσότερες φορές χρησιμοποιούν κοινά πρωτόκολλα όπως το TCP/IP. Αυτό το τελευταίο χαρακτηριστικό γνώρισμα επιτρέπει τη συμβατότητα με μια μεγάλη γκάμα όσον αφορά την κυρία εφαρμογή, δίκτυα, και παρέχουν έτσι συνδεσιμότητα σε μια εκτεταμένη βάση χρηστών ή μια υποδομή. ¶

3.1 ΣΧΕΤΙΚΗ ΕΡΕΥΝΑ

Σύμφωνα με τη εργασία των Jie Liu, Elaine Cheong και Feng Zhao (2005) κάποιος μπορεί να περιγράψει τους μServers σαν "ενσωματωμένες συσκευές δικτύου που δέχονται κατά απαίτηση τις εντολές από τους χρήστες και τις εκτελούν πάνω σε πραγματική πληροφορία, η οποία έχει συλλεχθεί από τους αισθητήρες". ¶Προχώρησαν στην ανάπτυξη ενός προσανατολισμένου σε υπηρεσίες λογισμικού με σκοπό την ζωντανή ενσωμάτωση ροής από τους αισθητήρες και τη διαμοίραση των υπολογιστικών αποτελεσμάτων σε ένα ευρύ σύνολο από χρήστες . ¶Κάθε χρήστης, που συνδέεται ενδεχομένως ταυτόχρονα με άλλους στο σύστημα, πρέπει να είναι σε θέση να θέσει αιτήματα και να ανακτήσει πληροφορίες. ¶Κατά τη διάρκεια της εργασίας τους, τα αιτήματα δεν είναι υποχρεωτικά σχετιζόμενα και στην πραγματικότητα ένας στόχος ήταν να αντιμετωπιστούν ως απολύτως ασυντόνιστα. ¶Η έρευνά τους δεν στράφηκε σε ένα συγκεκριμένο περιβάλλον ή εφαρμογή αλλά μάλλον η προσπάθεια ήταν να παραγάγει ένα πλήρες σύστημα μServer έτοιμο να δεχτεί τροποποιήσεις από τους χρήστες. Σαν¶ΣΣΑ επίδειξη ο Jie Liu και λοιποί [ 2005 ] πειραματίστηκαν με ένα δίκτυο αισθητήρων σε ένα γκαράζ στάθμευσης αυτοκινήτων εκτελώντας τρία ανεξάρτητα ερωτήματα χρηστών. ¶

¶Η εργασία του Jie Liu και λοιποί (2005) βασίστηκε πρώτιστα σε δύο άλλες έρευνες: ¶" A Spreadsheet Approach to Programming and Managing Sensor Networks " του Alec Woo, Siddharth Seth, Tim Olson, Jie Liu, και Feng Zhao (2005) και " Towards Semantic Services for Sensor-Rich Information Systems," από Jie Liu και Feng Zhao [ 2005 ]. ¶Οι πρώτοι [ Alec Woo και λοιποί 2005 ] ήταν μια προσπάθεια να απλοποιηθεί η διαχείριση δικτύων αισθητήρων. ¶Η κύρια δυσκολία που προσδιορίζεται σε αυτήν την έρευνα είναι ο προγραμματισμός του συστήματος με ένα αποτελεσματικό τρόπο. ¶Αυτή η δυσκολία σύμφωνα με τους αυτούς είναι εγγενής από το γεγονός ότι διάφορες διαφορετικές πλατφόρμες πρέπει να συνεργαστούν τέλεια: ¶Αισθητήρες, πύλες και servers. ¶Η δεύτερη πηγή [ Jie Liu, Feng Zhao 2005 ] υποστηρίζει ότι για να μπορέσουμε να έχουμε κλιμακούμενη πρόσβαση στα δεδομένα των αισθητήρων κάποιος θα πρέπει να ¶

" define an ontology and associated sensor information hierarchy for interpretation of raw data streams." ¶

Αυτό υποστηρίζουν ότι διαχειρίζεται με τη χρησιμοποίηση ενός κοινού μοντέλου για τις ερωτήσεις προς το σύστημα χωρίς να εξετάζονται πραγματικά τα ακατέργαστα δεδομένα των αισθητήρων που συσσωρεύονται από το σύστημα. ¶

Μια άλλη έρευνα που πραγματοποιήθηκε από Garcia-Zubia J., το Lopez de Ipina D. και Orduna P. του πανεπιστημίου Deusto στην Ισπανία [ Garcia και λοιποί 2005 ] στρέφεται στο θέμα μServers ως μέσο ενίσχυσης [ Garcia και λοιποί, iJoe 2005 ] του WebLab. ¶ Ο σχεδιασμός του WebLab ήταν πάντα στραμένος σύμφωνα με την έρευνα στο hardware αγνοώντας πτυχές όπως η εξελιξιμότητα, η προσβασιμότητα, η ασφάλεια και το φιλικό περιβάλλον προς το χρήστη. ¶Τα μέσα για να ενισχυθεί το σύστημά τους και να αντιμετωπίσουν αυτές τις απαιτήσεις επρόκειτο να εφαρμοστούν με τη χρήση μιας λύσης μServer. Με αυτό τον τρόπο κατάφεραν¶Με ταυτξφξ να ενισχύσουν την ευελιξία και την εξελιξιμότητα του συστήματος δεδομένου ότι μπορούσε τώρα να αγνοήσει τις λεπτομέρειες επικοινωνίας σε χαμηλό επίπεδο, να δικτυώσουν αρκετές από τις συσκευές του συστήματος ενσύρματα ή ασύρματα μέσω του TCP και να επιταχύνουν τη ροή δεδομένων μέσα από το δίκτυο. ¶Αυτό κατέστη δυνατό αφού με την υιοθέτηση τεχνικών microserver κάθε προγραμματιζόμενη συσκευή WebLab μετατράπηκε τώρα σε έναν κόμβο δικτύου. ¶Δυστυχώς αυτή η αναβάθμιση συνοδεύτηκε επίσης με ένα εγγενές κόστος στο διαχειριστή του δικτύου όπου θα έπρεπε τώρα να παρακολουθεί περισσότερες συσκευές. ¶

Όπως αναφέρθηκε νωρίτερα οι microservers μπορούν να είναι πολύ ωφέλιμοι ακόμα και μέσα σε ένα οικιακό περιβάλλον. Η εργασία των Masuda Υ., Sekimoto Μ., Nambu Μ., Higashi Υ., Fujimoto Τ., Chihara Κ. και Tamura Υ. (2005) παρέχει ένα τέτοιο παράδειγμα. Η μελέτη τους διερευνά τις δυνατότητες της επέκτασης λύσεων υγειονομικής περίθαλψης στο οικιακό περιβάλλον μέσω των microservers. Ένα πλαίσιο τηλεϊατρικής που βασίζεται σε microservers σύμφωνα με Masuda και λοιπούς (2005) θα ήταν σε θέση να διαβιβάσει τμήματα δεδομένων αρκετά για την παρακολούθηση της κατάστασης της υγείας των ενοίκων των σπιτιών. Για να αποδείξουν τις υποθέσεις τους οι ερευνητές εφάρμοσαν ένα σύστημα ελέγχου της λειτουργίας της καρδιάς και του αναπνευστικού συστήματος. Το σύστημα σχεδιάστηκε έτσι ώστε να μπορεί να επικοινωνεί ασύρματα με έναν παροχέα υγειονομικής περίθαλψης που θα μπορούσε να εποπτεύει την περιοχή. Ο παροχέα υγειονομικής περίθαλψης θα μπορούσε να έχει πρόσβαση στα στοιχεία των ασθενών από οπουδήποτε οποιαδήποτε στιγμή. Το TCP χρησιμοποιήθηκε για να συνδέσει τα υποσυστήματα. Τα αποτελέσματα ήταν πολύ ελπιδοφόρα, μια και το σύστημα αποδείχθηκε πολύ χρήσιμο τόσο για τον ιατρό όσο και για τον ασθενή.

¶

Λαμβάνοντας υπόψη όλα τα ανωτέρω, δεν είναι δύσκολο να εκτιμηθεί η σημασία των μServers όταν πρέπει να επεκτείνουμε το πλαίσιο λειτουργίας και την ευελιξία των εφαρμογών. ¶ Ταυτόχρονα μια έρευνα του 2004 επισημαίνει [ Schoellhammer και λοιποί 2004 ] πώς μια τέτοια εφαρμογή θα μπορούσε να αυξήσει τα οφέλη της χρήσης των μServers σε ενεργειακά θέματα. ¶Η έρευνα αναγνωρίζει ότι η μετάδοση ραδιοσημάτων είναι μεγάλος καταναλωτής ενέργειας σε δίκτυα αισθητήρων και για αυτό "μείωση δεδομένων πριν την εκπομπή, είτε με συμπίεση, είτε με απαλοιφή χαρακτηριστικών γνωρισμάτων θα ενισχύσει άμεσα και σημαντικά την διάρκεια ζωής του δικτύου". ¶Με άλλα λόγια, Schoellhammer και λοιποί δείχνουν ότι εάν ένας μServer μπορεί επαρκώς και αξιόπιστα να επεξεργαστεί τα ακατέργαστα δεδομένα των αισθητήρων, μπορεί έπειτα να ελαχιστοποιήσει την κατανάλωση ενέργειας μέσω της μετάδοσης των μικρότερων πακέτων δεδομένων προς το λαμβάνον δίκτυο. ¶

Ο βαθμός αποδοτικότητας σε αυτήν την διαδικασία διύλισης δεδομένων μπορεί φυσικά να συζητηθεί πολύ και ποικίλλει από εφαρμογή σε εφαρμογή. ¶Σύμφωνα με την εργασία τους [ Schoellhammer και λοιποί 2004 ], "σε πολλές περιπτώσεις, είναι πρόωρο να αρχίσει κάποιος να εφαρμόζει τεχνικές απάλειψης χαρακτηριστικών γνωρισμάτων. ¶Οι χρήστες δεν καταλαβαίνουν ακόμα σε ποιες μορφές θα εμφανιστούν ενδιαφέροντα δεδομένα και δεν μπορούν συνεπώς να διακινδυνεύσουν αυτόματα απαλείφοντας ότι θεωρούν άνευ σημασίας" και συνεχίζουν για να υπογραμμίσουν ότι " η επιστήμη των υπολογιστών αρχίζει μόλις να αναπτύσσει τους αλγόριθμους για τη συλλογή χωρικά κατανεμημένων χαρακτηριστικών γνωρισμάτων επί τόπου ". ¶Για αυτόν το λόγω η εργασία τους συνεχίζει όχι μόνο δηλώνοντας και αποδεικνύοντας τα παραπάνω αλλά παρέχοντας και αξιολογώντας ένα απλό προσωρινό αλγόριθμο συμπίεσης. ¶

Η εργασία των Kamin Whitehouse, Feng Zhao και Jie Liu [ Whitehouse Κ., Zhao F. και Liu J. 2006 ] παρουσιάζει ένα πλαίσιο αποκαλούμενο "Semantic Streams" που επιτρέπει στους χρήστες να θέτουν επεξηγηματικές ερωτήσεις πέρα από τις σημασιολογικές ερμηνείες των δεδομένων των αισθητήρων. ¶Αυτό που επιτεύχθηκε ήταν η ανάπτυξη μιας λύσης που επιτρέπει στους χρήστες των δικτύων αισθητήρων να θέτουν ερωτήσεις σε μια αφηρημένη μορφή παρά την επαναίτηση ακατέργαστων δεδομένων από τους αισθητήρες. ¶Παραδείγματος χάριν, αντί της αίτησης των ακατέργαστων δεδομένων των μαγνητομέτρων, οι ερωτήσεις των χρηστών είναι εάν τα οχήματα είναι αυτοκίνητα ή φορτηγά, εάν ο σκοπός του μαγνητομέτρου είναι να καταγραφεί το μέγεθος του διερχόμενου οχήματος [ Whitehouse Κ., Zhao F. και Liu J. 2006 ]. ¶Ολοκληρώνοντας την εργασία τους Whitehouse, Zhao και Liu [ Whitehouse Κ., Zhao F. και Liu J. 2006 ] υποστηρίζουν ότι η εργασία τους επιτρέπει στους απλούς ανθρώπους να κάνουν ερωτήσεις υψηλού επιπέδου πληροφορίας σε δίκτυα αισθητήρων αντί της εξέτασης χαμηλού επιπέδου δεδομένων, που πρέπει να υποβληθούν σε επεξεργασία προκειμένου να προκύπτει νόημα. ¶

Μια άλλη ενδιαφέρουσα μελέτη είναι αυτή Stathopoulos Τ. Lewis G. Heidermann J. και Estrin D. [ 2006 ]. ¶Προτείνουν ότι αντί να ορίσουν μServers για να διευκολύνουν αποκλειστικά την εξαγωγή και επεξεργασία δεδομένων, κόκκοι θα μπορούσαν να οριστούν για να χειριστούν την εξαγωγή δεδομένων οι οποίοι στην συνέχεια θα μπορούσαν να επιτηρούνται από ένα σύνολο microservers. Ως ¶Ωσψω κόκκους, η μελέτη τους περιγράφει τους 8-bit κόμβους αισθητήρων, τυπικά ανεπαρκείς για άλλες εργασίες αλλά ικανούς να διαβιβάσουν ακατέργαστα δεδομένα αισθητήρων. Α¶υτό το ονομάζουν Mote Herding. ¶ To Mote Herding είναι βασικά μια αρχιτεκτονική συστημάτων ευρείας κλίμακας και τα ετερογενών δικτύων αισθητήρων που ομαδοποιεί τους κόκκους σε αγέλες συνδεόμενα με ένα δίκτυο πολλαπλών αναπηδήσεων με ένα μServer ενεργώντας ως ποιμένας. ¶Οι μServers, όντας 32-bit κόμβοι, εκμεταλλεύονται τις μεγαλύτερες επικοινωνιακές και υπολογιστικές δυνατότητες τους για να δημιουργήσουν ένα δίκτυο με πολλές αγέλες κόκκων που διαμορφώνει ένα κοπάδι. ¶Τα οφέλη αυτής της μεθόδου είναι καλύτερα σε απόκριση, αξιοπιστία και ενεργειακή αποδοτικότητα σε σύγκριση με τις ομοιογενείς αρχιτεκτονικές. ¶Για να υποστηρίξει τις θέσεις της η ομάδα, δημιούργησε συστήματα αρκετά απομακρυσμένα που υλοποιούσαν ένα σύνολο υπηρεσιών: ¶μια υπηρεσία δρομολόγησης κόκκου, μια υπηρεσία αξιοπιστίας δεδομένων και μια υπηρεσία ανακάλυψης πόρων. ¶Επιπλέον η τελευταία υπηρεσία αποτελούνται από τρεις άλλες υπηρεσίες. ¶Τα αποτελέσματα έδειξαν ότι η υπηρεσία δρομολόγησης κόκκου διατήρησε τη συνδεσιμότητα κοντά στο 100% και αυτό το κοπάδι κόκκων ήταν σε θέση να παραδώσει όλα τα δεδομένα με ελάχιστα υψηλότερη κατανάλωση όσον αφορά τον έλεγχο και ελάχιστη απόκριση. ¶