套接口選項
在前面的幾章中，我們討論了使用套接口的基礎內容。現在我們要來探討一些可用的其他的特徵。在我們掌握了這一章的概念之後，我們就爲後面的套接口的高級主題做好了準備。在這一章，我們將會專注於下列主題：
如何使用getsockopt(2)函數獲得套接口選項值
如何使用setsockopt(2)函數設置套接口選項值
如何使用這些常用的套接口選項
得到套接口選項
有時，一個程序需要確定爲當前爲一個套接口進行哪些選項設置。這對於一個子程序庫函數尤其如此，因爲這個庫函數並不知道爲這個套接口進行哪些設置，而這個套接口需要作爲一個參數進行傳遞。程序也許需要知道類似於流默認使用的緩衝區的大小。
允許我們得到套接口選項值的爲getsockopt函數。這個函數的概要如下：
#include <sys/types.h>
#include <sys/socket.h>
int getsockopt(int s,
int level,
int optname,
void *optval,
socklen_t *optlen);
函數參數描述如下：
1 要進行選項檢驗的套接口s
2 選項檢驗所在的協議層level
3 要檢驗的選項optname
4 指向接收選項值的緩衝區的指針optval
5 指針optlen同時指向輸入緩衝區的長度和返回的選項長度值
當函數成功時返回0。當發生錯誤時會返回-1，而錯誤原因會存放在外部變量errno中。
協議層參數指明瞭我們希望訪問一個選項所在的協議棧。通常我們需要使用下面中的一個：
SOL_SOCKET來訪問套接口層選項
SOL_TCP來訪問TCP層選項
我們在這一章的討論將會專注於SOL_SOCKET層選項的使用。
參數optname爲一個整數值。在這裏所使用的值首先是由所選用的level參數來確定的。在一個指定的協議層，optname參數將會確定我們希望訪問哪一個選項。下表列出了一些層與選項的組合值：
協議層 選項名字
SOL_SOCKET SO_REUSEADDR
SOL_SOCKET SO_KKEPALIVE
SOL_SOCKET SO_LINGER
SOL_SOCKET SO_BROADCAST
SOL_SOCKET SO_OOBINLINE
SOL_SOCKET SO_SNDBUF
SOL_SOCKET SO_RCVBUF
SOL_SOCKET SO_TYPE
SOL_SOCKET SO_ERROR
SOL_TCP SO_NODELAY
上表所列的大多數選項爲套接口選項，其中的層是由SOL_SOCKET指定的。爲了比較的目的包含了一個TCP層套接口選項，其中的層是由SOL_TCP指定的。
大多數套接口選項獲得後存放在int數據類型中。當查看手冊頁時，數據類型int通常會有一些假設，除非表明了其他東西。當使用一個布爾值時，當值爲非零時，int表示TRUE，而如果爲零，則表示FALSE。
應用getsockopt(2)
在這一部分，我們將會編譯並運行一個getsndrcv.c的程序，這個程序會獲得並報告一個套接口的發送以及接收緩衝區的大小尺寸。
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <assert.h>
static void bail(const char *on_what)
{
if(errno != 0)
{
fputs(strerror(errno),stderr);
fputs(": ",stderr);
}
fputs(on_what,stderr);
fputc('/n',stderr);
exit(1);
}
int main(int argc,char **argv)
{
int z;
int s=-1;
int sndbuf=0;
int rcvbuf=0;
socklen_t optlen;
s = socket(PF_INET,SOCK_STREAM,0);
if(s==-1)
bail("socket(2)");
optlen = sizeof sndbuf;
z = getsockopt(s,SOL_SOCKET,SO_SNDBUF,&sndbuf,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET,"
"SO_SNDBUF)");
assert(optlen == sizeof sndbuf);
optlen = sizeof rcvbuf;
z = getsockopt(s,SOL_SOCKET,SO_RCVBUF,&rcvbuf,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET,"
"SO_RCVBUF)");
assert(optlen == sizeof rcvbuf);
printf("Socket s: %d/n",s);
printf("Send buf: %d bytes/n",sndbuf);
printf("Recv buf: %d bytes/n",rcvbuf);
close(s);
return 0;
}
程序的運行結果如下：
$ ./getsndrcv
socket s : 3
Send buf: 65535 bytes
Recv buf: 65535 bytes
設置套接口選項
如果認爲套接口的默認發送以及接收緩衝區的尺寸太大時，作爲程序設計者的我們可以將其設計爲一個小的緩衝區。當我們程序一個程序的幾個實例同時運行在我們的系統上時，這顯得尤其重要。
可以通過setsockopt(2)函數來設計套接口選項。這個函數的概要如下：
#include <sys/types.h>
#include <sys/socket.h>
int setsockopt(int s,
int level,
int optname,
const void *optval,
socklen_t optlen);
這個函數與我們在上面所討論的getsockopt函數類似，setsockopt函數的參數描述如下：
1 選項改變所要影響的套接口s
2 選項的套接口層次level
3 要設計的選項名optname
4 指向要爲新選項所設置的值的指針optval
5 選項值長度optlen
這個函數參數與上面的getsockopt函數的參數的區別就在於最後一個參數僅是傳遞參數值。在這種情況下只是一個輸入值。
應用setsockopt函數
下面的例子代碼爲一個套接口改變了發送以及接收緩衝區的尺寸。在設置完這些選項以後，程序會得到並報告實際的緩衝區尺寸。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <assert.h>
static void bail(const char *on_what)
{
if(errno!=0)
{
fputs(strerror(errno),stderr);
fputs(": ",stderr);
}
fputs(on_what,stderr);
fputc('/n',stderr);
exit(1);
}
int main(int argc,char **argv)
{
int z;
int s=-1;
int sndbuf=0;
int rcvbuf=0;
socklen_t optlen;
s = socket(PF_INET,SOCK_STREAM,0);
if(s==-1)
bail("socket(2)");
sndbuf = 5000;
z = setsockopt(s,SOL_SOCKET,SO_SNDBUF,&sndbuf,sizeof sndbuf);
if(z)
bail("setsockopt(s,SOL_SOCKET,"
"SO_SNDBUF)");
rcvbuf = 8192;
z = setsockopt(s,SOL_SOCKET,SO_RCVBUF,&rcvbuf,sizeof rcvbuf);
if(z)
bail("setsockopt(s,SOL_SOCKET,"
"SO_RCVBUF)");
optlen = sizeof sndbuf;
z = getsockopt(s,SOL_SOCKET,SO_SNDBUF,&sndbuf,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET,"
"SO_SNDBUF)");
assert(optlen == sizeof sndbuf);
optlen = sizeof rcvbuf;
z = getsockopt(s,SOL_SOCKET,SO_RCVBUF,&rcvbuf,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET"
"SO_RCVBUF)");
assert(optlen == sizeof rcvbuf);
printf("Socket s: %d/n",s);
printf(" Send buf: %d bytes/n",sndbuf);
printf(" Recv buf: %d bytes/n",rcvbuf);
close(s);
return 0;
}
程序的運行結果如下：
$ ./setsndrcv
Socket s : 3
Send buf: 10000 bytes
Recv buf: 16384 bytes
$
在
這裏我們要注意程序所報告的結果。他們看上去似乎是所指定的原始尺寸的兩倍。這個原因可以由Linux內核源碼模塊net/core/sock.c中查
到。我們可以查看一下SO_SNDBUF以及SO_RCVBUF的case語句。下面一段是由內核模塊sock.c中摘錄的一段處理SO_SNDBUF的
代碼：
398 case SO_SNDBUF:
399
403
404 if (val > sysctl_wmem_max)
405 val = sysctl_wmem_max;
406 set_sndbuf:
407 sk->sk_userlocks |= SOCK_SNDBUF_LOCK;
408 if ((val * 2) < SOCK_MIN_SNDBUF)
409 sk->sk_sndbuf = SOCK_MIN_SNDBUF;
410 else
411 sk->sk_sndbuf = val * 2;
412
413
417 sk->sk_write_space(sk);
418 break;
由這段代碼我們可以看到實際發生在SO_SNDBUF上的事情：
1 檢測SO_SNDBUF選項值來確定他是否超過了緩衝區的最大值
2 如果步驟1中的SO_SNDBUF選項值沒有超過最大值，那麼就使用這個最大值，而不會向調用者返回錯誤代碼
3 如果SO_SNDBUF選項值的2倍小於套接口SO_SNDBUF的最小值，那麼實際的SO_SNDBUF則會設置爲SO_SNDBUF的最小值，否則則會SO_SNDBUF選項值則會設置爲SO_SNDBUF選項值的2倍
從這裏我們可以看出SO_SNDBUF的選項值只是所用的一個提示值。內核會最終確定爲SO_SNDBUF所用的最佳值。
查看更多的內核源碼，我們可以看到類似的情況也適用於SO_RCVBUF選項。如下面的一段摘錄的代碼：
427 case SO_RCVBUF:
428
432
433 if (val > sysctl_rmem_max)
434 val = sysctl_rmem_max;
435 set_rcvbuf:
436 sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
437
452 if ((val * 2) < SOCK_MIN_RCVBUF)
453 sk->sk_rcvbuf = SOCK_MIN_RCVBUF;
454 else
455 sk->sk_rcvbuf = val * 2;
456 break;
取得套接口類型
實際上我們只可以得到一些套接口選項。SO_TYPE就是其中的一例。這個選項會允許傳遞套接口的一個子函數來確定正在處理的是哪一種套接口類型。
如下面是一段得到套接口s類型的示例代碼：
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <assert.h>
static void bail(const char *on_what)
{
if(errno!=0)
{
fputs(strerror(errno),stderr);
fputs(": ",stderr);
}
fputs(on_what,stderr);
fputc('/n',stderr);
exit(1);
}
int main(int argc,char **argv)
{
int z;
int s = -1;
int so_type = -1;
socklen_t optlen;
s = socket(PF_INET,SOCK_STREAM,0);
if(s==-1)
bail("socket(2)");
optlen = sizeof so_type;
z = getsockopt(s,SOL_SOCKET,SO_TYPE,&so_type,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET,"
"SO_TYPE)");
assert(optlen == sizeof so_type);
printf("Socket s: %d/n",s);
printf(" SO_TYPE : %d/n",so_type);
printf(" SO_STREAM = %d/n",SOCK_STREAM);
close(s);
return 0;
}
程序的運行結果如下：
$./gettype
Socket s: 3
SO_TYPE : 1
SO_STREAM = 1
設置SO_REUSEADDR選項
在第11章，"併發客戶端服務器"的第一部分中，提供並測試了一個使用fork系統調用設計的服務器。圖12.1顯示了在一個telnet命令與服務器建立連接之後的三個步驟。
這些步驟如下：
1 啓動服務器進程(PID 926)。他監聽客戶端連接。
2 啓動客戶端進程(telnet命令)，並且連接到服務器進程(PID 926)。
3 通過fork調用創建服務器子進程，這會保留的原始的父進程(PID 926)並且創建一個新的子進程(PID 927)。
4 連接的客戶端套接口由服務器父進程(PID 926)關閉，僅在子進程(PID 927)中保持連接的客戶端套接口處理打開狀態。
5 telnet命令與服務器子進程(PID 927)隨意交互，而獨立於父進程(PID 926)。
在步驟5，有兩個套接口活動：
服務器(PID 926)監聽192.168.0.1：9099
客戶端由套接口192.168.0.1：9099進行服務(PID 927)，他連接到客戶端地址192.168.0.2：1035
客戶端由進程ID 927進行服務。這意味着我們可以殺掉進程ID 926，而客戶端仍可以繼續被服務。然而，卻不會有新的連接連接到服務器，因爲並沒有服務器監聽新的連接(監聽服務器PID 926已被殺死)
現
在如果我們重啓服務器來監聽新的連接，就會出現問題。當新的服務器進程試着綁定IP地址192.168.0.1：9099時，bind函數就會返回
EADDRINUSE的錯誤代碼。這個錯誤代碼表明IP已經在9099端口上使用。這是因爲進程PID
927仍然在忙於服務一個客戶端。地址192.168.0.1：9099仍爲這個進程所使用。
這個問題的解決辦法就是殺掉進程927,這個關閉套接口並且釋放IP地址和端口。然而，如果正在被服務的客戶是我們所在公司的CEO，這樣的做法似乎不是一個選擇。同時，其他的部門也會抱怨我們爲什麼要重新啓動服務器。
這個問題的一個好的解決辦法就是使用SO_REUSEADDR套接口選項。所有的服務器都應使用這個選項，除非有一個更好的理由不使用。爲了有效的使用這個選項，我們應在監聽連接的服務器中執行下面的操作：
1 使用通常的socket函數創建一個監聽套接口
2 調用setsockopt函數設置SO_REUSEADDR爲TRUE
3 調用bind函數
套接口現在被標記爲可重用。如果監聽服務器進程因爲任何原因終止，我們可以重新啓動這個服務器。當一個客戶正爲另一個服務器進程使用同一個IP和端口號進行服務時尤其如此。
爲了有效的使用SO_REUSEADDR選項，需要考慮下面的情況：
在監聽模式下並沒有同樣的IP地址和端口號的其他套接口
所有的同一個IP地址和端口號的套接口必須將SO_REUSEADDR選項設置爲TRUE
這就意味着一個指定的IP地址和端口號對上只可以用一個監聽器。如果這樣的套接口已經存在，那麼設置這樣的選項將不會達到我們的目的。
只有所有存在的同一個地址和端口號的套接口有這個選項設置，將SO_REUSEADDR設置爲TRUE纔會有效。如果存在的套接口沒有這個選項設置，那麼bind函數就會繼續並且會返回一個錯誤號。
下面的代碼顯示如何將這個選項設置爲TRUE：
#define TRUE 1
#define FALSE 0
int z;
int s;
int so_reuseaddr = TRUE;
z = setsockopt(s,SOL_SOCKET,SO_REUSEADDR,
&so_reuseaddr,
sizeof so_reuseaddr);
如果需要SO_REUSEADDR選項可以由getsockopt函數進行查詢。
設置SO_LINGER選項
另一個常用的選項就是SO_LINGER選項。與SO_REUSEADDR選項所不同的是這個選項所用的數據類型並不是一個簡單的int類型。
SO_LINGER選項的目的是控制當調用close函數時套接口如何關閉。這個選項只適用於面向連接的協議，例如TCP。
內核的默認行爲是允許close函數立即返回給調用者。如果可能任何未發送的TCP/IP數據將會進行傳送，但是並不會保證這樣做。因爲close函數會立即向調用者返回控制權，程序並沒有辦法知道最後一位的數據是否進行了發送。
SO_LINGER選項可以作用在套接口上，來使得程序阻塞close函數調用，直到所有最後的數據傳送到遠程端。而且，這會保證兩端的調用知道套接口正常關閉。如果失敗，指定的選項超時，並且向調用程序返回一個錯誤。
通過使用不同的SO_LINGER選項值，可以應用一個最後場景。如果調用程序希望立即中止通信，可以在linger結構中設置合適的值。然後，一個到close的調用會初始化一個通信中止連接，而丟棄所有未發送的數據，並立即關閉套接口。
SO_LINGER的這種操作模式是由linger結構來控制的：
struct linger {
int l_onoff;
int l_linger;
};
成員l_onoff爲一個布爾值，非零值表示TRUE，而零則表示FALSE。這個選項的三個值描述如下：
1 設置l_onoff爲FALSE使得成員l_linger被忽略，而使用默認的close行爲。也就是說，close調用會立即返回給調用者，如果可能將會傳輸任何未發送的數據。
2
設置l_onoff爲TRUE將會使得成員l_linger的值變得重要。當l_linger非零時，這代表應用在close函數調用上的以秒計的超時時
限。如果超時發生之前，有未發送的數據並且成功關閉，函數將會成功返回。否則，將會返回錯誤，而將變量errno的值設置爲EWOULDBLOCK。
3 將l_onoff設置爲TRUE而l_linger設置爲零時使得連接中止，在調用close時任何示發送的數據都會丟棄。
我
們也許希望得到一些建議，在我們的程序中使用SO_LINGER選項，並且提供一個合理的超時時限。然後，可以檢測由close函數的返回值來確定連接是
否成功關閉。如果返回了一個錯誤，這就告知我們的程序也許遠程程序並不能接收我們發送的全部數據。相對的，他也許僅意味着連接關閉時發生的問題。
然
而，我們必須保持清醒，這樣的方法在一些服務器設計中會產生新的問題。當在close函數調用上將SO_LINGER選項配置爲超時(linger)，當
我們的服務器在close函數調用中執行超時時會阻止其他的客戶端進行服務。如果我們正在一個進程中服務多個客戶端進程時就會存在這個問題。使用默認的行
爲也許更爲合適，因爲這允許close函數立即返回。而任何未發送的數據也會爲內核繼續發送。
最後，如果程序或是服務器知道連接應何時中止時可以使用中止行爲。這也許適用於當服務器認爲沒有訪問權限的用戶正試着進行訪問的情況。這種情況下的客戶並不會得到特別的關注。
下面的代碼是一個使用SO_LINGER選項的例子，使用30秒的超時時限：
#define TRUE 1
#define FALSE 0
int z; int s;
struct linger so_linger;
...
so_linger.l_onoff = TRUE;
so_linger.l_linger = 30;
z = setsockopt(s,
SOL_SOCKET,
SO_LINGER,
&so_linger,
sizeof so_linger);
if ( z )
perror("setsockopt(2)");
下面的例子顯示瞭如何設置SO_LINGER的值來中止套接口s上的當前連接：
#define TRUE 1
#define FALSE 0
int z;
int s;
struct linger so_linger;
...
so_linger.l_onoff = TRUE;
so_linger.l_linger = 0;
z = setsockopt(s,
SOL_SOCKET,
SO_LINGER,
&so_linger,
sizeof so_linger);
if ( z )
perror("setsockopt(2)");
close(s);
在上面的這個例子中，當調用close函數時，套接口s會立即中止。中止的語義是通過將超時值設置爲0來實現的。
設置SO_KKEPALIVE選項
當使用連接時，有時他們會空閒相當長的時間。例如，建立一個telnet會話通過訪問股票交易服務。他也許會執行一些初始的查詢，然後離開連接而保持服務打開，因爲他希望回來查詢更多的內容。然而，同時連接處理空閒狀態，也許一次就是一個小時。
任
何一個服務器認爲他有一個連接的客戶時會爲其分配相應的資源。如果服務器是一個派生類型(fork)，那麼整個Linux進程及其相應的內存都分配給這個
客戶。如果事情順利，這個場景並不會產生任何問題。然而當出現網絡崩潰時，困難出現了，我們所有的578個客戶都會從我們的股票交易服務中失去連接。
在網絡服務恢復後，578個客戶會試着連接到我們的服務器，重建連接。這對於我們來說是一個真實的問題，因爲我們的服務器在之前並沒有意識到他失去了空閒客戶－－SO_KKEPALIVE來解決這個問題。
下面的例子顯示瞭如何在套接口s上使用SO_KKEPALIVE選項，從而一個斷開的空閒連接可以被檢測到：
#define TRUE 1
#define FALSE 0
int z; int s;
int so_keepalive;
...
so_keepalive = TRUE;
z = setsockopt(s,
SOL_SOCKET,
SO_KEEPALIVE,
&so_keepalive,
sizeof so_keepalive);
if ( z )
perror("setsockopt(2)");
在上面的例子中設置了SO_KEEPALIVE選項，這樣當套接口連接空閒相當長的時間時，一個探測信息(probe message)就會發送到遠程端。這通常是在兩個小時的無活動後完成的。對於一個保持活動的探測信息會有三個可能的反應。他們分別是：
1 端會合適的返回表明一切正常。並沒有向程序返回任何指示信息，因爲這是程序假定的開始。
2 端響應表明他對連接一無所知。這表明端自上次通信以後與主機進行重新連接。這樣當下次套接口操作時會向程序返回ECONNRESET錯誤代碼。
3 端沒有響應。在這種情況下，內核也許做了幾次嘗試進行連接。如果沒有響應請求，TCP通常會在大約11分鐘內放棄。當這種情況發生時，在下次套接口操作時會返回ETIMEOUT錯誤。其他的錯誤，例如EHOSTUNREACH會在網絡不再能到達主機時返回。
SO_KEEPALIVE
所調用的時間框架會限制他通常的用處。探測信息也只在大約兩個小時的無活動後纔會發送。然後，當沒有響應時，在連接返回錯誤時還需要另外的11分鐘。無論
怎樣，這個選項確實允許探測空閒的無連接套接口，然後由服務器進行關閉。相應的，支持長空閒連接的服務器應允許這個特徵。
設置SO_BROADCAST選項
我們現在還沒有討論到使用UDP進行廣播的主題。然而，我們很容易意識到廣播功能的誤用以及所造成的網絡災難。爲了避免在沒有計劃廣播時進行廣播，套接口禁用了廣播功能。如果確實需要廣播，那麼C程序員要爲套接口的這個功能處理相應的麻煩。
SO_BROADCAST是一個布爾標誌選項，由int數據類型進行設置。下面的例子顯示瞭如何設置SO_BROADCAST選項：
#define TRUE 1
#define FALSE 0
int z;
int s;
int so_broadcast;
...
so_broadcast = TRUE;
z = setsockopt(s,
SOL_SOCKET,
SO_BROADCAST,
&so_broadcast,
sizeof so_broadcast);
if ( z )
perror("setsockopt(2)");
如果要setsockopt函數返回零，套接口s已經允許進行廣播。然而在這裏要注意的是所選用的套接口類型必須具有廣播功能，例如UDP套接口。
設置SO_OOBINLINE選項
在一些情況下，已發送的數據也許會超過所限制的數據量。通常，這些越界的數據是用不同於通常的數據接收函數來進行接收的。然而有時卻更喜歡使用通常的方式來接收這些越界數據。當選擇這種方法時，越界數據作爲通常數據流的一部分在通常數據之前到達。
要使用這個特徵，我們可以用下面的代碼來完成：
#define TRUE 1
#define FALSE 0
int z;
int s;
int so_oobinline;
...
so_oobinline = TRUE;
z = setsockopt(s,
SOL_SOCKET,
SO_OOBINLINE,
&so_oobinline,
sizeof so_oobinline);
if ( z )
perror("setsockopt(2)");
在設置了SO_OOBINLINE選項之後，越界數據就會與通常數據一起接收。在這種方式下，所接收的越界數據與通常數據相同。
SO_PASSCRED與SO_PEERCRED選項
這些選項僅適用於PF_UNIX(PF_LOCAL)套接口。這些選項用來在當前主機的本地套接口上控制與傳遞憑證。這也許是最難掌握的一個主題。就現在而言，我們只需要簡單的注意到，如果我們希望編寫服務本地主機客戶的服務程序時，我們也許會對這兩個選項感興趣。
