socket編程原理
1、問題的引入
1) 普通的I/O操作過程:
UNIX系統的I/O命令集，是從Maltics和早期系統中的命令演變出來的，其模式爲打開一讀/寫一關閉（open-write-read-close）。在一個用戶進程進行I/O操作時，它首先調用“打開”獲得對指定文件或設備的使用權，並返回稱爲文件描述符的整型數，以描述用戶在打開的文件或設備上進行I/O操作的進程。然後這個用戶進程多次調用“讀/寫”以傳輸數據。當所有的傳輸操作完成後，用戶進程關閉調用，通知操作系統已經完成了對某對象的使用。
2) TCP/IP協議被集成到UNIX內核中
TCP/IP協議被集成到UNIX內核中時，相當於在UNIX系統引入了一種新型的I/O操作。UNIX用戶進程與網絡協議的交互作用比用戶進程與傳統的I/O設備相互作用複雜得多。首先，進行網絡操作的兩個進程在不同機器上，如何建立它們之間的聯繫？其次，網絡協議存在多種，如何建立一種通用機制以支持多種協議？這些都是網絡應用編程界面所要解決的問題。
3) 需要一種通用的網絡編程接口: 獨立於具體協議和通用的網絡編程
在UNIX系統中，網絡應用編程界面有兩類：UNIX BSD的套接字（socket）和UNIX System V的TLI。由於Sun公司採用了支持TCP/IP的UNIX BSD操作系統，使TCP/IP的應用有更大的發展，其網絡應用編程界面──套接字（socket）在網絡軟件中被廣泛應用，至今已引進微機操作系統DOS和Windows系統中，成爲開發網絡應用軟件的強有力工具，本章將要詳細討論這個問題。
開始使用套接字編程之前，首先必須建立以下概念。
2.1 網間進程通信
進程通信的概念最初來源於單機系統。由於每個進程都在自己的地址範圍內運行，爲保證兩個相互通信的進程之間既互不干擾又協調一致工作，操作系統爲進程通信提供了相應設施，
如UNIX BSD有：管道（pipe）、命名管道（named pipe）軟中斷信號（signal）
UNIX system V有：消息（message）、共享存儲區（shared memory）和信號量（semaphore)等.
他們都僅限於用在本機進程之間通信。網間進程通信要解決的是不同主機進程間的相互通信問題（可把同機進程通信看作是其中的特例）。爲此，首先要解決的是網間進程標識問題。同一主機上，不同進程可用進程號（process ID）唯一標識。但在網絡環境下，各主機獨立分配的進程號不能唯一標識該進程。例如，主機A賦於某進程號5，在B機中也可以存在5號進程，因此，“5號進程”這句話就沒有意義了。 其次，操作系統支持的網絡協議衆多，不同協議的工作方式不同，地址格式也不同。因此，網間進程通信還要解決多重協議的識別問題。 爲了解決上述問題，TCP/IP協議引入了下列幾個概念。
1）端口
網絡中可以被命名和尋址的通信端口，是操作系統可分配的一種資源。
按照OSI七層協議的描述，傳輸層與網絡層在功能上的最大區別是傳輸層提供進程通信能力。從這個意義上講，網絡通信的最終地址就不僅僅是主機地址了，還包括可以描述進程的某種標識符。爲此，TCP/IP協議提出了協議端口（protocol port，簡稱端口）的概念，用於標識通信的進程。
端口是一種抽象的軟件結構（包括一些數據結構和I/O緩衝區）。應用程序（即進程）通過系統調用與某端口建立連接（binding）後，傳輸層傳給該端口的數據都被相應進程所接收，相應進程發給傳輸層的數據都通過該端口輸出。在TCP/IP協議的實現中，對端口的操作類似於一般的I/O操作，進程獲取一個端口，相當於獲取本地唯一的I/O文件，可以用一般的讀寫原語訪問之。 類似於文件描述符，每個端口都擁有一個叫端口號（port
number）的整數型標識符，用於區別不同端口。
由於TCP/IP傳輸層的兩個協議TCP和UDP是完全獨立的兩個軟件模塊，因此各自的端口號也相互獨立，如TCP有一個255號端口，UDP也可以有一個255號端口，二者並不衝突。
端口號的分配是一個重要問題。有兩種基本分配方式：第一種叫全局分配，這是一種集中控制方式，由一個公認的中央機構根據用戶需要進行統一分配，並將結果公佈於衆。第二種是本地分配，又稱動態連接，即進程需要訪問傳輸層服務時，向本地操作系統提出申請，操作系統返回一個本地唯一的端口號，進程再通過合適的系統調用將自己與該端口號聯繫起來（綁紮）。TCP/IP端口號的分配中綜合了上述兩種方式。TCP/IP將端口號分爲兩部分，少量的作爲保留端口，以全局方式分配給服務進程。因此，每一個標準服務器都擁有一個全局公認的端口（即周知口，well-known
port），即使在不同的機器上，其端口號也相同。剩餘的爲自由端口，以本地方式進行分配。TCP和UDP均規定，小於256的端口號才能作保留端口。
2）地址
網絡通信中通信的兩個進程分別在不同的機器上。在互連網絡中，兩臺機器可能位於不同的網絡，這些網絡通過網絡互連設備（網關，網橋，路由器等）連接。因此需要三級尋址：
1. 某一主機可與多個網絡相連，必須指定一特定網絡地址；
2. 網絡上每一臺主機應有其唯一的地址；
3. 每一主機上的每一進程應有在該主機上的唯一標識符。
通常主機地址由網絡ID和主機ID組成，在TCP/IP協議中用32位整數值表示；TCP和UDP均使用16位端口號標識用戶進程。
3）網絡字節順序
不同的計算機存放多字節值的順序不同，有的機器在起始地址存放低位字節（小端序，低價先存），有的存高位字節（大端序，高價先存）。爲保證數據的正確性，在網絡協議中須指定網絡字節順序。TCP/IP協議使用16位整數和32位整數的高價先存格式，它們均含在協議頭文件中。 詳解http://blog.csdn.net/hguisu/article/details/7449955#t1
4）連接
兩個進程間的通信鏈路稱爲連接。連接在內部表現爲一些緩衝區和一組協議機制，在外部表現出比無連接高的可靠性。
5）半相關
綜上所述，網絡中用一個三元組可以在全局唯一標誌一個進程：
（協議，本地地址，本地端口號） 這樣一個三元組，叫做一個半相關（half-association），它指定連接的每半部分。
6）全相關
一個完整的網間進程通信需要由兩個進程組成，並且只能使用同一種高層協議。也就是說，不可能通信的一端用TCP協議，而另一端用UDP協議。因此一個完整的網間通信需要一個五元組來標識：
（協議，本地地址，本地端口號，遠地地址，遠地端口號） 這樣一個五元組，叫做一個相關（association），即兩個協議相同的半相關才能組合成一個合適的相關，或完全指定組成一連接。
2.2 服務方式
在網絡分層結構中，各層之間是嚴格單向依賴的，各層次的分工和協作集中體現在不同層之間的界面上。“服務”是描述不同層之間關係的抽象概念，即網絡中各層向緊鄰上層提供的一組操作。下層是服務提供者，上層是請求服務的用戶。服務的表現形式是原語（primitive），如系統調用或庫函數。系統調用是操作系統內核向網絡應用程序或高層協議提供的服務原語。網絡中的n層總要向n+1層提供比n-1層更完備的服務，否則n層就沒有存在的價值。 在OSI的術語中，網絡層及其以下各層又稱爲通信子網，只提供點到點通信，沒有程序或進程的概念。而傳輸層實現的是“端到端”通信，引進網間進程通信概念，同時也要解決差錯控制，流量控制，數據排序（報文排序），連接管理等問題，爲此提供不同的服務方式：
1）面向連接（虛電路）或無連接
面向連接服務（TCP協議）：是電話系統服務模式的抽象，即每一次完整的數據傳輸都要經過建立連接，使用連接，終止連接的過程。在數據傳輸過程中，各數據分組不攜帶目的地址，而使用連接號（connect
ID）。本質上，連接是一個管道，收發數據不但順序一致，而且內容相同。TCP協議提供面向連接的虛電路。
無連接服務（UDP協議）：是郵政系統服務的抽象，每個分組都攜帶完整的目的地址，各分組在系統中獨立傳送。無連接服務不能保證分組的先後順序，不進行分組出錯的恢復與重傳，不保證傳輸的可靠性。UDP協議提供無連接的數據報服務。
下面給出這兩種服務的類型及應用中的例子：
![]()
2）順序
在網絡傳輸中，兩個連續報文在端－端通信中可能經過不同路徑，這樣到達目的地時的順序可能會與發送時不同。“順序”是指接收數據順序與發送數據順序相同。TCP協議提供這項服務。
3）差錯控制
保證應用程序接收的數據無差錯的一種機制。檢查差錯的方法一般是採用檢驗“檢查和（Checksum）”的方法。而保證傳送無差錯的方法是雙方採用確認應答技術。TCP協議提供這項服務。
4）流控制
在數據傳輸過程中控制數據傳輸速率的一種機制，以保證數據不被丟失。TCP協議提供這項服務。
5）字節流
字節流方式指的是僅把傳輸中的報文看作是一個字節序列，不提供數據流的任何邊界。TCP協議提供字節流服務。
6）報文
接收方要保存發送方的報文邊界。UDP協議提供報文服務。
7）全雙工/半雙工
端－端間數據同時以兩個方向/一個方向傳送。
8）緩存/帶外數據
在字節流服務中，由於沒有報文邊界，用戶進程在某一時刻可以讀或寫任意數量的字節。爲保證傳輸正確或採用有流控制的協議時，都要進行緩存。但對某些特殊的需求，如交互式應用程序，又會要求取消這種緩存。 在數據傳送過程中，希望不通過常規傳輸方式傳送給用戶以便及時處理的某一類信息，如UNIX系統的中斷鍵（Delete或Control-c）、終端流控制符（Control-s和Control-q），稱爲帶外數據。邏輯上看，好象用戶進程使用了一個獨立的通道傳輸這些數據。該通道與每對連接的流相聯繫。由於Berkeley
Software Distribution中對帶外數據的實現與RFC 1122中規定的Host Agreement不一致,爲了將互操作中的問題減到最小，應用程序編寫者除非與現有服務互操作時要求帶外數據外，最好不使用它。
2.3 客戶/服務器模式
在TCP/IP網絡應用中，通信的兩個進程間相互作用的主要模式是客戶/服務器模式（Client/Server model），即客戶向服務器發出服務請求，服務器接收到請求後，提供相應的服務。客戶/服務器模式的建立基於以下兩點：首先，建立網絡的起因是網絡中軟硬件資源、運算能力和信息不均等，需要共享，從而造就擁有衆多資源的主機提供服務，資源較少的客戶請求服務這一非對等作用。其次，網間進程通信完全是異步的，相互通信的進程間既不存在父子關係，又不共享內存緩衝區，因此需要一種機制爲希望通信的進程間建立聯繫，爲二者的數據交換提供同步，這就是基於不同的客戶/服務器模式的TCP/IP。 客戶/服務器模式在工作過程中採取的是主動請求方式：
服務器方：
首先服務器方要先啓動，並根據請求提供相應服務：
1. 打開一通信通道並告知本地主機，它願意在某一公認地址上（周知口，如FTP爲21）接收客戶請求；
2. 等待客戶請求到達該端口；
3. 接收到重複服務請求，處理該請求併發送應答信號。接收到併發服務請求，要激活一新進程來處理這個客戶請求（如UNIX系統中用fork、exec）。新進程處理此客戶請求，並不需要對其它請求作出應答。服務完成後，關閉此新進程與客戶的通信鏈路，並終止。
4. 返回第二步，等待另一客戶請求。
5. 關閉服務器
客戶方：
1. 打開一通信通道，並連接到服務器所在主機的特定端口；
2. 向服務器發服務請求報文，等待並接收應答；繼續提出請求......
3. 請求結束後關閉通信通道並終止。
從上面所描述過程可知：
1. 客戶與服務器進程的作用是非對稱的，因此編碼不同。
2. 服務進程一般是先於客戶請求而啓動的。只要系統運行，該服務進程一直存在，直到正常或強迫終止。
2.4 套接字類型
TCP/IP的socket提供下列三種類型套接字。
流式套接字（SOCK_STREAM）：
提供了一個面向連接、可靠的數據傳輸服務，數據無差錯、無重複地發送，且按發送順序接收。內設流量控
制，避免數據流超限；數據被看作是字節流，無長度限制。文件傳送協議（FTP）即使用流式套接字。
數據報式套接字（SOCK_DGRAM）：
提供了一個無連接服務（UDP）。數據包以獨立包形式被髮送，不提供無錯保證，
數據可能丟失或重複，並且接收順序混亂。網絡文件系統（NFS）使用數據報式套接字。
原始式套接字（SOCK_RAW） ：
該接口允許對較低層協議，如IP、ICMP直接訪問。常用於檢驗新的協議實現或訪問現有服務中配置的新設備。
2.4 典型套接字調用過程舉例
如前所述，TCP/IP協議的應用一般採用客戶/服務器模式，因此在實際應用中，必須有客戶和服務器兩個進程，並且首先啓動服務器，其系統調用時序圖如下。 面向連接的協議（如TCP）的套接字系統調用如圖2.1所示：
![]()
服務器必須首先啓動，直到它執行完accept()調用，進入等待狀態後，方能接收客戶請求。假如客戶在此前啓動，則connect()將返回出錯代碼，連接不成功。
無連接協議（UDP）的套接字調用如圖2.2所示：
![]()
無連接服務器也必須先啓動，否則客戶請求傳不到服務進程。無連接客戶不調用connect()。因此在數據發送之前，客戶與服務器之間尚未建立完全相關，但各自通過socket()和bind()建立了半相關。發送數據時，發送方除指定本地套接字號外，還需指定接收方套接字號，從而在數據收發過程中動態地建立了全相關。
實例
本實例使用面向連接協議的客戶/服務器模式，其流程如圖2.3所示：
![]()
服務器方程序：
-
-
#include <winsock.h>
-
#include <stdio.h>
-
#define TRUE 1
-
-
-
-
-
main( )
-
{
-
int sock, length;
-
struct sockaddr_in server;
-
struct sockaddr tcpaddr;
-
int msgsock;
-
char buf[1024];
-
int rval, len;
-
-
-
sock = socket(AF_INET, SOCK_STREAM, 0);
-
if (sock < 0) {
-
perror(“opening stream socket”);
-
exit(1);
-
}
-
-
-
server.sin_family = AF_INET;
-
server.sin_port = INADDR_ANY;
-
if (bind(sock, (struct sockaddr *)&server, sizeof(server)) < 0) {
-
perror(“binding stream socket”);
-
exit(1);
-
}
-
-
-
length = sizeof(server);
-
if (getsockname(sock, (struct sockaddr *)&server, &length) < 0) {
-
perror(“getting socket name”);
-
exit(1);
-
}
-
printf(“socket port #%d/n”, ntohs(server.sin_port));
-
-
-
listen(sock, 5);
-
len = sizeof(struct sockaddr);
-
do {
-
msgsock = accept(sock, (struct sockaddr *)&tcpaddr, (int *)&len);
-
if (msgsock == -1)
-
perror(“accept”);
-
else do{
-
memset(buf, 0, sizeof(buf));
-
if ((rval = recv(msgsock, buf, 1024)) < 0)
-
perror(“reading stream message”);
-
if (rval == 0)
-
printf(“ending connection /n”);
-
else
-
printf(“-->;%s/n”, buf);
-
}while (rval != 0);
-
closesocket(msgsock);
-
} while (TRUE);
-
-
-
-
exit(0);
-
}
客戶方程序：
-
-
#include <winsock.h>
-
#include <stdio.h>
-
#define DATA “half a league, half a league ...”
-
-
-
-
main(argc, argv)
-
int argc;
-
char *argv[ ];
-
{
-
int sock;
-
struct sockaddr_in server;
-
struct hostent *hp, *gethostbyname( );
-
char buf[1024];
-
-
-
sock = socket(AF_INET, SOCK_STREAM, 0);
-
if (sock < 0) {
-
perror(“opening stream socket”);
-
exit(1);
-
}
-
-
-
server.sin_family = AF_INET;
-
hp = gethostbyname(argv[1]);
-
if (hp == 0) {
-
fprintf(stderr, “%s: unknown host /n”, argv[1]);
-
exit(2);
-
}
-
memcpy((char*)&server.sin_addr, (char*)hp->;h_addr, hp->;h_length);
-
sever.sin_port = htons(atoi(argv[2]));
-
-
if (connect(sock, (struct sockaddr*)&server, sizeof(server)) < 0) {
-
perror(“connecting stream socket”);
-
exit(3);
-
}
-
-
if (send(sock, DATA, sizeof(DATA)) < 0)
-
perror(“sending on stream socket”);
-
closesocket(sock);
-
exit(0);
-
}
2.5 一個通用的實例程序
在上一節中，我們介紹了一個簡單的socket程序實例。從這個例子我們可以看出，使用socket編程幾乎有一個模式，即所有的程序幾乎毫無例外地按相同的順序調用相同的函數。因此我們可以設想，設計一箇中間層，它向上提供幾個簡單的函數，程序只要調用這幾個函數就可以實現普通的網絡數據傳輸，程序設計者不必太多地關心socket程序設計的細節。 本節我們將介紹一個通用的網絡程序接口，它向上層提供幾個簡單的函數，程序設計者只要使用這幾個函數就可以完成絕大多數網絡數據傳輸。這些函數將socket編程和上層隔離開來，它使用面向連接的流式套接字，採用非阻塞的工作機制，程序只要調用這些函數查詢網絡消息並作出相應的響應即可。這些函數包括：
l InitSocketsStruct：初始化socket結構，獲取服務端口號。客戶程序使用。
l InitPassiveSock：初始化socket結構，獲取服務端口號，建立主套接字。服務器程序使用。
l CloseMainSock：關閉主套接字。服務器程序使用。
l CreateConnection：建立連接。客戶程序使用。
l AcceptConnection：接收連接。服務器程序使用。
l CloseConnection：關閉連接。
l QuerySocketsMsg：查詢套接字消息。
l SendPacket：發送數據。
l RecvPacket：接收數據。
2.5.1 頭文件
/* File Name: tcpsock.h */
/* 頭文件包括socket程序經常用到的系統頭文件（本例中給出的是SCO Unix下的頭文件，其它版本的Unix的頭文件可能略有不同），並定義了我們自己的兩個數據結構及其實例變量，以及我們提供的函數說明。*/
-
-
-
-
#include <stdio.h>
-
#include <string.h>
-
#include <time.h>
-
#include <sys/tape.h>
-
#include <sys/signal.h>
-
#include <sys/errno.h>
-
#include <sys/types.h>
-
#include <sys/ioctl.h>
-
#include <sys/select.h>
-
#include <sys/socket.h>
-
#include <sys/stat.h>
-
#include <sys/netinet/in.h>
-
#include <sys/netinet/tcp.h>
-
#include <arpa/inet.h>
-
#include <netdb.h>
-
-
typedef struct SocketsMsg{
-
int AcceptNum;
-
int ReadNum;
-
int ReadQueue[32];
-
int WriteNum;
-
int WriteQueue[32];
-
int ExceptNum;
-
int ExceptQueue[32];
-
} SocketsMsg;
-
typedef struct Sockets {
-
int DaemonSock;
-
int SockNum;
-
int Sockets[64];
-
fd_set readfds, writefds, exceptfds;
-
-
} Sockets;
-
-
Sockets Mysock;
-
SocketsMsg SockMsg;
-
-
int InitSocketsStruct(char * servicename) ;
-
int InitPassiveSock(char * servicename) ;
-
void CloseMainSock();
-
int CreateConnection(struct in_addr *sin_addr);
-
int AcceptConnection(struct in_addr *IPaddr);
-
int CloseConnection(int Sockno);
-
int QuerySocketsMsg();
-
int SendPacket(int Sockno, void *buf, int len);
-
int RecvPacket(int Sockno, void *buf, int size);
2.5.2 函數源文件
-
-
-
#include "tcpsock.h"
-
-
int InitSocketsStruct(char * servicename)
-
-
-
-
{
-
struct servent *servrec;
-
struct sockaddr_in serv_addr;
-
-
if ((servrec = getservbyname(servicename, "tcp")) == NULL) {
-
return(-1);
-
}
-
bzero((char *)&Mysock, sizeof(Sockets));
-
Mysock.Port = servrec->s_port;
-
return(1);
-
}
-
-
int InitPassiveSock(char * servicename)
-
-
-
-
{
-
int mainsock, flag=1;
-
struct servent *servrec;
-
struct sockaddr_in serv_addr;
-
-
if ((servrec = getservbyname(servicename, "tcp")) == NULL) {
-
return(-1);
-
}
-
bzero((char *)&Mysock, sizeof(Sockets));
-
Mysock.Port = servrec->s_port;
-
-
if((mainsock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
-
return(-2);
-
}bzero((char *)&serv_addr, sizeof(serv_addr));
-
serv_addr.sin_family = AF_INET;
-
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
-
serv_addr.sin_port = servrec->s_port;
-
if (bind(mainsock, (struct sockaddr*)&serv_addr, sizeof(serv_addr)) < 0) {
-
close(mainsock);
-
return(-3);
-
}
-
-
if (listen(mainsock, 5) == -1) {
-
close(mainsock);
-
return(-4);
-
}
-
-
-
if (ioctl(mainsock, FIONBIO, &flag) == -1) {
-
close(mainsock);
-
return(-5);
-
}
-
-
Mysock.DaemonSock = mainsock;
-
FD_SET(mainsock, &Mysock.readfds);
-
FD_SET(mainsock, &Mysock.exceptfds);
-
return(1);
-
}
-
void CloseMainSock()
-
-
{
-
close(Mysock.DaemonSock);
-
FD_CLR(Mysock.DaemonSock, &Mysock.readfds);
-
FD_CLR(Mysock.DaemonSock, &Mysock.exceptfds);
-
}
-
-
int CreateConnection(struct in_addr *sin_addr)
-
-
-
-
-
{
-
struct sockaddr_in server;
-
int tmpsock, flag=1, i;
-
-
if ((tmpsock = socket(AF_INET, SOCK_STREAM, 0)) < 0)
-
return(-1);
-
-
server.sin_family = AF_INET;
-
server.sin_port = Mysock.Port;
-
server.sin_addr.s_addr = sin_addr->s_addr;
-
-
if (ioctl(tmpsock, FIONBIO, &flag) == -1) {
-
close(tmpsock);
-
return(-2);
-
}
-
-
-
if (connect(tmpsock, (struct sockaddr *)&server, sizeof(server)) < 0) {
-
if ((errno != EWOULDBLOCK) && (errno != EINPROGRESS)) {
-
-
-
close(tmpsock);
-
return(-3);
-
}
-
}
-
FD_SET(tmpsock, &Mysock.readfds);
-
FD_SET(tmpsock, &Mysock.writefds);
-
FD_SET(tmpsock, &Mysock.exceptfds);
-
-
i = 0;
-
while (Mysock.Sockets[i] != 0) i++;
-
if (i >= 64) {
-
close(tmpsock);
-
return(-4);
-
}
-
-
Mysock.Sockets[i] = tmpsock;
-
Mysock.SockNum++;
-
return(i);
-
}
-
-
int AcceptConnection(struct in_addr *IPaddr)
-
-
{
-
int newsock, len, flag=1, i;
-
struct sockaddr_in addr;
-
-
len = sizeof(addr);
-
bzero((char *)&addr, len);
-
if ((newsock = accept(Mysock.DaemonSock, &addr, &len)) == -1)
-
return(-1);
-
-
-
ioctl(newsock, FIONBIO, &flag);
-
-
FD_SET(newsock, &Mysock.readfds);
-
FD_SET(newsock, &Mysock.writefds);
-
FD_SET(newsock, &Mysock.exceptfds);
-
-
-
IPaddr->s_addr = addr.sin_addr.s_addr;
-
-
i = 0;
-
while (Mysock.Sockets[i] != 0) i++;
-
if (i >= 64) {
-
close(newsock);
-
return(-4);
-
}
-
-
Mysock.Sockets[i] = newsock;
-
Mysock.SockNum++;
-
return(i);
-
}
-
int CloseConnection(int Sockno)
-
-
{
-
int retcode;
-
-
if ((Sockno >= 64) || (Sockno < 0) || (Mysock.Sockets[Sockno] == 0））
-
return(0);
-
retcode = close(Mysock.Sockets[Sockno]);
-
FD_CLR(Mysock.Sockets[Sockno], &Mysock.readfds);
-
FD_CLR(Mysock.Sockets[Sockno], &Mysock.writefds);
-
FD_CLR(Mysock.Sockets[Sockno], &Mysock.exceptfds);
-
-
Mysock.Sockets[Sockno] = 0;
-
Mysock.SockNum--;
-
return(retcode);
-
}
-
int QuerySocketsMsg()
-
-
-
{
-
fd_set rfds, wfds, efds;
-
int retcode, i;
-
struct timeval TimeOut;
-
-
rfds = Mysock.readfds;
-
wfds = Mysock.writefds;
-
efds = Mysock.exceptfds;
-
TimeOut.tv_sec = 0;
-
TimeOut.tv_usec = 0;
-
-
bzero((char *)&SockMsg, sizeof(SockMsg));
-
if ((retcode = select(64, &rfds, &wfds, &efds, &TimeOut)) == 0)
-
return(0);
-
-
if (FD_ISSET(Mysock.DaemonSock, &rfds))
-
SockMsg.AcceptNum = 1;
-
-
for (i=0; i<64; i++)
-
{
-
if ((Mysock.Sockets[i] > 0) && (FD_ISSET(Mysock.Sockets[i], &rfds)))
-
SockMsg.ReadQueue[SockMsg.ReadNum++] = i;
-
}
-
-
for (i=0; i<64; i++)
-
{
-
if ((Mysock.Sockets[i] > 0) && (FD_ISSET(Mysock.Sockets[i], &wfds)))
-
SockMsg.WriteQueue[SockMsg.WriteNum++] = i;
-
}
-
-
if (FD_ISSET(Mysock.DaemonSock, &efds))
-
SockMsg.AcceptNum = -1;
-
-
for (i=0; i<64; i++)
-
{
-
if ((Mysock.Sockets[i] > 0) && (FD_ISSET(Mysock.Sockets[i], &efds)))
-
SockMsg.ExceptQueue[SockMsg.ExceptNum++] = i;
-
}
-
return(retcode);
-
}
-
-
int SendPacket(int Sockno, void *buf, int len)
-
-
{
-
int actlen;
-
-
if ((Sockno >= 64) || (Sockno < 0) || (Mysock.Sockets[Sockno] == 0))
-
return(0);
-
-
if ((actlen = send(Mysock.Sockets[Sockno], buf, len, 0)) < 0)
-
return(-1);
-
return(actlen);
-
}
-
-
int RecvPacket(int Sockno, void *buf, int size)
-
-
-
{
-
int actlen;
-
if ((Sockno >= 64) || (Sockno < 0) || (Mysock.Sockets[Sockno] == 0))
-
return(0);
-
if ((actlen = recv(Mysock.Sockets[Sockno], buf, size, 0)) < 0)
-
return(0-errno);
-
return(actlen);
-
}
2.5.3 簡單服務器程序示例
-
-
-
-
-
#include "tcpsock.c"
-
main(argc, argv)
-
int argc;
-
char **argv;
-
{
-
struct in_addr sin_addr;
-
int retcode, i;
-
char buf[32];
-
-
-
-
-
-
-
(void) signal(SIGINT, CloseMainSock);
-
(void) signal(SIGQUIT, CloseMainSock);
-
(void) signal(SIGTERM, CloseMainSock);
-
-
if ((retcode = InitPassiveSock("TestService")) < 0) {
-
printf("InitPassiveSock: error code = %d\n", retcode);
-
exit(-1);
-
}
-
-
while (1) {
-
retcode = QuerySocketsMsg();
-
if (SockMsg.AcceptNum == 1) {
-
retcode = AcceptConnection(&sin_addr);
-
printf("retcode = %d, IP = %s \n", retcode, inet_ntoa(sin_addr.s_addr));
-
}
-
else if (SockMsg.AcceptNum == -1)
-
printf("Daemon Sockets error.\n");
-
for (i=0; i<SockMsg.ReadNum; i++) {
-
if ((retcode = RecvPacket(SockMsg.ReadQueue[i], buf, 32)) > 0)
-
printf("sockno %d Recv string = %s \n", SockMsg.ReadQueue[i], buf);
-
else
-
CloseConnection(SockMsg.ReadQueue[i]);
-
}
-
}
-
}
2.5.4 簡單客戶程序示例
-
-
-
-
-
-
-
-
#include "tcpsock.h"
-
-
main(argc, argv)
-
int argc;
-
char **argv;
-
{
-
char cmd_buf[16];
-
struct in_addr sin_addr;
-
int sockno1, retcode;
-
char *buf = "This is a string for test.";
-
sin_addr.s_addr = inet_addr("166.111.5.249");
-
-
if ((retcode = InitSocketsStruct("TestService")) < 0) {
-
printf("InitSocketsStruct: error code = %d\n", retcode);
-
exit(1);
-
}
-
-
while (1) {
-
printf(">");
-
gets(cmd_buf);
-
if (!strncmp(cmd_buf, "conn", 4)) {
-
retcode = CreateConnection(&sin_addr);
-
printf("return code: %d\n", retcode);
-
}
-
else if(!strncmp(cmd_buf, "send", 4)) {
-
printf("Sockets Number:");
-
scanf("%d", &sockno1);
-
retcode = SendPacket(sockno1, buf, 26);
-
printf("return code: %d\n", retcode, sizeof(buf));
-
}
-
else if (!strncmp(cmd_buf, "close", 4)) {
-
printf("Sockets Number:");
-
scanf("%d", &sockno1);
-
retcode = CloseConnection(sockno1);
-
printf("return code: %d\n", retcode);
-
}
-
else if (!strncmp(cmd_buf, "quit", 4))
-
exit(0);
-
else
-
putchar('\007');
-
}
-
}
爲了更好地說明套接字編程原理，下面給出幾個基本套接字系統調用說明。
3.1 創建套接字──socket()
應用程序在使用套接字前，首先必須擁有一個套接字，系統調用socket()嚮應用程序提供創建套接字的手段，其調用格式如下：
-
SOCKET PASCAL FAR socket(int af, int type, int protocol);
該調用要接收三個參數：af、type、protocol。參數af（地址族 address-family）指定通信發生的區域，UNIX系統支持的地址族有：AF_UNIX、AF_INET、AF_NS等，而DOS、WINDOWS中僅支持AF_INET（AF_INET：Internet協議族（TCP/IP）），它是網際網區域。因此，地址族與協議族相同。參數type
描述要建立的套接字的類型。參數protocol說明該套接字使用的特定協議，如果調用者不希望特別指定使用的協議，則置爲0，使用默認的連接模式。根據這三個參數建立一個套接字，並將相應的資源分配給它，同時返回一個整型套接字號。因此，socket()系統調用實際上指定了相關五元組中的“協議”這一元。
3.2 指定本地地址──bind()
當一個套接字用socket()創建後，存在一個名字空間(地址族),但它沒有被命名。bind()將套接字地址（包括本地主機地址和本地端口地址）與所創建的套接字號聯繫起來，即將名字賦予套接字，以指定本地半相關。其調用格式如下：
-
int PASCAL FAR bind(SOCKET s, const struct sockaddr FAR * name, int namelen);
參數s：是由socket()調用返回的並且未作連接的套接字描述符(套接字號)。
參數name： 是賦給套接字s的本地地址（名字），其長度可變，結構隨通信域的不同而不同。
參數namelen：表明了name的長度。
如果沒有錯誤發生，bind()返回0。否則返回值SOCKET_ERROR。
地址在建立套接字通信過程中起着重要作用，作爲一個網絡應用程序設計者對套接字地址結構必須有明確認識。例如，UNIX BSD有一組描述套接字地址的數據結構，其中使用TCP/IP協議的地址結構爲：
-
struct sockaddr_in{
-
short sin_family;
-
u_short sin_port;
-
struct in_addr sin_addr;
-
char sin_zero[8];
-
}
3.3 建立套接字連接──connect()與accept()
這兩個系統調用用於完成一個完整相關的建立，其中connect()用於建立連接。無連接的套接字進程也可以調用connect()，但這時在進程之間沒有實際的報文交換，調用將從本地操作系統直接返回。這樣做的優點是程序員不必爲每一數據指定目的地址，而且如果收到的一個數據報，其目的端口未與任何套接字建立“連接”，便能判斷該端口不可操作。而accept()用於使服務器等待來自某客戶進程的實際連接。
connect()的調用格式如下：
-
int PASCAL FAR connect(SOCKET s, const struct sockaddr FAR * name, int namelen);
參數s：是欲建立連接的本地套接字描述符。
參數name：指出說明對方套接字地址結構的指針。
namele：對方套接字地址長度由namelen說明。
如果沒有錯誤發生，connect()返回0。否則返回值SOCKET_ERROR。在面向連接的協議中，該調用導致本地系統和外部系統之間連接實際建立。
由於地址族總被包含在套接字地址結構的前兩個字節中，並通過socket()調用與某個協議族相關。因此bind()和connect()無須協議作爲參數。
accept()的調用格式如下：
-
SOCKET PASCAL FAR accept(SOCKET s, struct sockaddr FAR* addr, int FAR* addrlen);
參數s：爲本地套接字描述符，在用做accept()調用的參數前應該先調用過listen()。
參數addr： 指向客戶方套接字地址結構的指針，用來接收連接實體的地址。addr的確切格式由套接字創建時建立的地址族決定。
參數addrlen: 爲客戶方套接字地址的長度（字節數）。如果沒有錯誤發生，accept()返回一個SOCKET類型的值，表示接收到的套接字的描述符。否則返回值INVALID_SOCKET。
accept()用於面向連接服務器。參數addr和addrlen存放客戶方的地址信息。調用前，參數addr 指向一個初始值爲空的地址結構，而addrlen 的初始值爲0；調用accept()後，服務器等待從編號爲s的套接字上接受客戶連接請求，而連接請求是由客戶方的connect()調用發出的。當有連接請求到達時，accept()調用將請求連接隊列上的第一個客戶方套接字地址及長度放入addr 和addrlen，並創建一個與s有相同特性的新套接字號。新的套接字可用於處理服務器併發請求。
四個套接字系統調用，socket()、bind()、connect()、accept()，可以完成一個完全五元相關的建立。socket()指定五元組中的協議元，它的用法與是否爲客戶或服務器、是否面向連接無關。bind()指定五元組中的本地二元，即本地主機地址和端口號，其用法與是否面向連接有關：在服務器方，無論是否面向連接，均要調用bind()；在客戶方，若採用面向連接，則可以不調用bind()，而通過connect()自動完成。若採用無連接，客戶方必須使用bind()以獲得一個唯一的地址。
以上討論僅對客戶/服務器模式而言，實際上套接字的使用是非常靈活的，唯一需遵循的原則是進程通信之前，必須建立完整的相關。
3.4 監聽連接──listen()
此調用用於面向連接服務器，表明它願意接收連接。listen()需在accept()之前調用，其調用格式如下：
int PASCAL FAR listen(SOCKET s, int backlog);
參數s標識一個本地已建立、尚未連接的套接字號，服務器願意從它上面接收請求。backlog表示請求連接隊列的最大長度，用於限制排隊請求的個數，目前允許的最大值爲5。如果沒有錯誤發生，listen()返回0。否則它返回SOCKET_ERROR。
listen()在執行調用過程中可爲沒有調用過bind()的套接字s完成所必須的連接，並建立長度爲backlog的請求連接隊列。
調用listen()是服務器接收一個連接請求的四個步驟中的第三步。它在調用socket()分配一個流套接字，且調用bind()給s賦於一個名字之後調用，而且一定要在accept()之前調用。
2.3節中提到客戶/服務器模式中，有兩種類型的服務：重複服務和併發服務。accept()調用爲實現併發服務提供了極大方便，因爲它要返回一個新的套接字號，其典型結構爲：
-
int initsockid, newsockid;
-
if ((initsockid = socket(....)) < 0)
-
error(“can’t create socket”);
-
if (bind(initsockid,....) < 0)
-
error(“bind error”);
-
if (listen(initsockid , 5) < 0)
-
error(“listen error”);
-
for (; {
-
newsockid = accept(initsockid, ...)
-
if (newsockid < 0)
-
error(“accept error“);
-
if (fork() == 0){
-
closesocket(initsockid);
-
do(newsockid);
-
exit(0);
-
}
-
closesocket(newsockid);
-
}
這段程序執行的結果是newsockid與客戶的套接字建立相關，子進程啓動後，關閉繼承下來的主服務器的initsockid,並利用新的newsockid與客戶通信。主服務器的initsockid可繼續等待新的客戶連接請求。由於在Unix等搶先多任務系統中，在系統調度下，多個進程可以同時進行。因此，使用併發服務器可以使服務器進程在同一時間可以有多個子進程和不同的客戶程序連接、通信。客戶程序看來，服務器可以同時併發地處理多個客戶的請求，這就是併發服務器名稱的來由。
面向連接服務器也可以是重複服務器，其結構如下：
-
int initsockid, newsockid;
-
if ((initsockid = socket(....))<0)
-
error(“can’t create socket”);
-
if (bind(initsockid,....)<0)
-
error(“bind error”);
-
if (listen(initsockid,5)<0)
-
error(“listen error”);
-
for (; {
-
newsockid = accept(initsockid, ...)
-
if (newsockid < 0)
-
error(“accept error“);
-
do(newsockid);
-
closesocket(newsockid);
-
}
重複服務器在一個時間只能和一個客戶程序建立連接，它對多個客戶程序的處理是採用循環的方式重複進行，因此叫重複服務器。併發服務器和重複服務器各有利弊：併發服務器可以改善客戶程序的響應速度，但它增加了系統調度的開銷；重複服務器正好與其相反，因此用戶在決定是使用併發服務器還是重複服務器時，要根據應用的實際情考網考網來定。
3.5 數據傳輸──send()與recv()
當一個連接建立以後，就可以傳輸數據了。常用的系統調用有send()和recv()。
send()調用用於在s指定的已連接的數據報或流套接字上發送輸出數據，格式如下：
-
int PASCAL FAR send(SOCKET s, const char FAR *buf, int len, int flags);
參數s:爲已連接的本地套接字描述符。
buf 指向存有發送數據的緩衝區的指針，
len :buf長度由len 指定。
flags 指定傳輸控制方式，如是否發送帶外數據等。
如果沒有錯誤發生，send()返回總共發送的字節數。否則它返回SOCKET_ERROR。
recv()調用用於在s指定的已連接的數據報或流套接字上接收輸入數據，格式如下：
-
int PASCAL FAR recv(SOCKET s, char FAR *buf, int len, int flags);
參數s 爲已連接的套接字描述符。
buf:指向接收輸入數據緩衝區的指針，
len :buf長度由len 指定。
flags 指定傳輸控制方式，如是否接收帶外數據等。
如果沒有錯誤發生，recv()返回總共接收的字節數。如果連接被關閉，返回0。否則它返回SOCKET_ERROR。
3.6 輸入/輸出多路複用──select()
select()調用用來檢測一個或多個套接字的狀態。對每一個套接字來說，這個調用可以請求讀、寫或錯誤狀態方面的信息。請求給定狀態的套接字集合由一個fd_set結構指示。在返回時，此結構被更新，以反映那些滿足特定條件的套接字的子集，同時， select()調用返回滿足條件的套接字的數目，其調用格式如下：
int PASCAL FAR select(int nfds, fd_set FAR * readfds, fd_set FAR * writefds, fd_set FAR * exceptfds, const struct timeval FAR * timeout);
參數nfds:指明被檢查的套接字描述符的值域，此變量一般被忽略。
參數readfds:指向要做讀檢測的套接字描述符集合的指針，調用者希望從中讀取數據。
參數writefds :指向要做寫檢測的套接字描述符集合的指針。
exceptfds指向要檢測是否出錯的套接字描述符集合的指針。
imeout指向select()函數等待的最大時間，如果設爲NULL則爲阻塞操作。
select()返回包含在fd_set結構中已準備好的套接字描述符的總數目，或者是發生錯誤則返回SOCKET_ERROR。
3.7 關閉套接字──closesocket()
closesocket()關閉套接字s，並釋放分配給該套接字的資源；如果s涉及一個打開的TCP連接，則該連接被釋放。closesocket()的調用格式如下：
-
BOOL PASCAL FAR closesocket(SOCKET s);
參數s待關閉的套接字描述符。如果沒有錯誤發生，closesocket()返回0。否則返回值SOCKET_ERROR。
4、TCP（socket建立）連接的時間
TCP建立連接，根據網絡環境不同，使用的時間如下：
1、本機的話，通信內容直接走內存。
2、局域網走網卡，然後通過交換機，指定到相應主機。tcp建立3次握手，一般耗0.6毫秒左右。
3、外網通過網卡->路由器->互聯網。
![]()
5、TCP粘包的問題
1、什麼是粘包：
簡單的說就是通過TCP協議發送了多條獨立的數據，但接收的時候，有些數據不幸的合併成了一個。比如客戶端向服務器發送兩個命令：
1)Hello
2)world
但是服務器接收的時候，很可能不是分兩次接收，而是一次接收到 Helloworld
2、粘包出現原因：
由於TCP協議本身的機制（面向連接的可靠地協議-三次握手機制）客戶端與服務器會維持一個連接（Channel），數據在連接不斷開的情況下，可以持續不斷地將多個數據包發往服務器，但是如果發送的網絡數據包太小，那麼他本身會啓用Nagle算法（可配置是否啓用）對較小的數據包進行合併（基於此，TCP的網絡延遲要UDP的高些）然後再發送（超時或者包大小足夠）。那麼這樣的話，服務器在接收到消息（數據流）的時候就無法區分哪些數據包是客戶端自己分開發送的，這樣產生了粘包；服務器在接收到數據庫後，放到緩衝區中，如果消息沒有被及時從緩存區取走，下次在取數據的時候可能就會出現一次取出多個數據包的情況，造成粘包現象（確切來講，對於基於TCP協議的應用，不應用包來描述，而應
用 流來描述），個人認爲服務器接收端產生的粘包應該與Linux內核處理socket的方式 select輪詢機制的線性掃描頻度無關。
再說UDP：本身作爲無連接的不可靠的傳輸協議（適合頻繁發送較小的數據包），他不會對數據包進行合併發送（也就沒有Nagle算法之說了），他直接是一端發送什麼數據，直接就發出去了，既然他不會對數據合併，每一個數據包都是完整的（數據+UDP頭+IP頭等等發一次數據封裝一次）也就沒有粘包一說了。
也就是說：UDP不是流協議，有消息邊界，不存在粘包的問題。要丟就是整個包都丟了。
原因：
1)、可能是IP分片傳輸導致的，也可能是傳輸過程中丟失部分包導致出現的半包
2)、爲了提高傳輸速度和效率, 把發送緩衝區中的數據拼爲一個數據包發送到目的地
比如:發送方需要等緩衝區滿才發送出去，造成粘包
3)、接收方不及時接收緩衝區的包，造成多個包接收。
2、解決方案：
1）、一個是採用分隔符的方式，即我們在封裝要傳輸的數據包的時候，採用固定的符號作爲結尾符（數據中不能含結尾符），這樣我們接收到數據後，如果出現結尾標識，即人爲的將粘包分開，如果一個包中沒有出現結尾符，認爲出現了分包，則等待下個包中出現後 組合成一個完整的數據包，這種方式適合於文本傳輸的數據，如採用/r/n之類的分隔符；
2）、另一種是採用在數據包中添加長度的方式，即在數據包中的固定位置封裝數據包的長度信息（或可計算數據包總長度的信息），服務器接收到數據後，先是解析包長度，然後根據包長度截取數據包（此種方式常出現於自定義協議中），但是有個小問題就是如果客戶端第一個數據包數據長度封裝的有錯誤，那麼很可能就會導致後面接收到的所有數據包都解析出錯（由於TCP建立連接後流式傳輸機制），只有客戶端關閉連接後重新打開纔可以消除此問題，我在處理這個問題的時候對數據長度做了校驗，會適時的對接收到的有問題的包進行人爲的丟棄處理（客戶端有自動重發機制，故而在應用層不會導致數據的不完整性）；
3）另一種不建議的方式是TCP採用短連接處理粘包（這個得根據需要來，所以不建議）
6、TCP與UDP區別
TCP（Transmission Control Protocol）傳輸控制協議：
該協議主要用於在主機間建立一個虛擬連接，以實現高可靠性的數據包交換。IP協議可以進行IP數據包的分割和組裝，但是通過IP協議並不能清楚地瞭解到數據包是否順利地發送給目標計算機。而使用TCP協議就不同了，在該協議傳輸模式中在將數據包成功發送給目標計算機後，TCP會要求發送一個確認；如果在某個時限內沒有收到確認，那麼TCP將重新發送數據包。另外，在傳輸的過程中，如果接收到無序、丟失以及被破壞的數據包，TCP還可以負責恢復。
傳輸控制協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議，通常由IETF的RFC793說明。在簡化的計算機網絡OSI模型中，它完成運輸層所指定的功能。
TCP字節流：
打個比方比喻TCP，你家裏有個蓄水池，你可以裏面倒水，蓄水池上有個龍頭，你可以通過龍頭將水池裏的水放出來，然後用各種各樣的容器裝（杯子、礦泉水瓶、鍋碗瓢盆）接水。
上面的例子中，往水池裏倒幾次水和接幾次水是沒有必然聯繫的，也就是說你可以只倒一次水，然後分10次接完。另外，水池裏的水接多少就會少多少；往裏面倒多少水，就會增加多少水，但是不能超過水池的容量，多出的水會溢出。
結合TCP的概念，水池就好比接收緩衝區，倒水就相當於發送數據，接水就相當於讀取數據。好比你通過TCP連接給另一端發送數據，你只調用了一次write，發送了100個字節，但是對方可以分10次收完，每次10個字節；你也可以調用10次write，每次10個字節，但是對方可以一次就收完。（假設數據都能到達）但是，你發送的數據量不能大於對方的接收緩存（流量控制），如果你硬是要發送過量數據，則對方的緩存滿了就會把多出的數據丟棄。
UDP (User Datagram Protocol） 用戶數據報協議：
用戶數據報協議（UDP）是 ISO參考模型中一種無連接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務。 UDP 協議基本上是 IP 協議與上層協議的接口。 UDP協議適用端口分別運行在同一臺設備上的多個應用程序。
由於大多數網絡應用程序都在同一臺機器上運行，計算機上必須能夠確保目的地機器上的軟件程序能從源地址機器處獲得數據包，以及源計算機能收到正確的回覆。這是通過使用UDP 的“端口號”完成的。
UDP數據報：
UDP和TCP不同，發送端調用了幾次write，接收端必須用相同次數的read讀完。UPD是基於報文的，在接收的時候，每次最多隻能讀取一個報文，報文和報文是不會合並的，如果緩衝區小於報文長度，則多出的部分會被丟棄。也就說，如果不指定MSG_PEEK標誌，每次讀取操作將消耗一個報文。
區別：
1、基於連接與無連接
TCP---傳輸控制協議提供的是面向連接、可靠的字節流服務。當客戶和服務器彼此交換數據前，必須先在雙方之間建立一個TCP連接，之後才能傳輸數據。TCP提供超時重發，丟棄重複數據，檢驗數據，流量控制等功能，保證數據能從一端傳到另一端。
每個數據包的傳輸過程是：先建立鏈路、數據傳輸、然後清除鏈路。數據包不包含目的地址。受端和發端不但順序一致，而且內容相同。它的可靠性高。
UDP---用戶數據報協議是面向無連接的，每個數據包都有完整的源、目的地址及分組編號，各自在網絡中獨立傳輸，傳輸中不管其順序，數據到達收端後再進行排序組裝，遇有丟失、差錯和失序等情況，通過請求重發來解決。它的效率比較高。
UDP是一個簡單的面向數據報的運輸層協議。UDP不提供可靠性，它只是把應用程序傳給IP層的數據報發送出去，但是並不能保證它們能到達目的地。由於UDP在傳輸數據報前不用在客戶和服務器之間建立一個連接，且沒有超時重發等機制，故而傳輸速度很快。
3、UDP程序結構較簡單
4、流模式與數據報模式
5、TCP保證數據正確性，UDP可能丟包，TCP保證數據順序，UDP不保證
6、TCP提供可靠的字節流服務 ，UDP 並不提供 對IP協議的可靠機制、流控制以及錯誤恢復功能等。
