web-dev-qa-db-ja.com

閉じたローカルへの書き込みTCPソケットは失敗しません

ソケットに問題があるようです。以下に、サーバーとクライアントをフォークするコードをいくつか示します。サーバーはTCPソケットを開き、クライアントはそれに接続してから閉じます。スリープはタイミングを調整するために使用されます。クライアント側のclose（）の後、サーバーは書き込みを試みます（ ）TCP接続のそれ自体の終わりまで。write（2）のマニュアルページによると、これはshouldでSIGPIPEとEPIPE errnoが返されます。これは表示されません。サーバーの観点からは、ローカルの閉じたソケットへの書き込みsucceedsがなく、EPIPEがない場合、クライアントが閉じたことをサーバーが検出する方法を確認できませんソケット。

クライアントの端を閉じるクライアントと書き込みを試みるサーバーの間のギャップでは、netstatを呼び出すと、接続がCLOSE_WAIT/FIN_WAIT2状態にあることが示されるため、サーバーエンドは確実に書き込みを拒否できます。

参考までに、私はDebian Squeezeを使用していますが、uname-rは2.6.39-bpo.2-AMD64です。

何が起きてる？

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/socket.h>
#include <sys/select.h>
#include <netinet/tcp.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>

#include <netdb.h>

#define SERVER_ADDRESS "127.0.0.7"
#define SERVER_PORT 4777


#define myfail_if( test, msg ) do { if((test)){ fprintf(stderr, msg "\n"); exit(1); } } while (0)
#define myfail_unless( test, msg ) myfail_if( !(test), msg )

int connect_client( char *addr, int actual_port )
{
    int client_fd;

    struct addrinfo hint;
    struct addrinfo *ailist, *aip;


    memset( &hint, '\0', sizeof( struct addrinfo ) );
    hint.ai_socktype = SOCK_STREAM;

    myfail_if( getaddrinfo( addr, NULL, &hint, &ailist ) != 0, "getaddrinfo failed." );

    int connected = 0;
    for( aip = ailist; aip; aip = aip->ai_next ) {
        ((struct sockaddr_in *)aip->ai_addr)->sin_port = htons( actual_port );
        client_fd = socket( aip->ai_family, aip->ai_socktype, aip->ai_protocol );

        if( client_fd == -1) { continue; }
        if( connect( client_fd, aip->ai_addr, aip->ai_addrlen) == 0 ) {
            connected = 1;
            break;
        }
        close( client_fd );
    }

    freeaddrinfo( ailist );

    myfail_unless( connected, "Didn't connect." );
    return client_fd;
}


void client(){
    sleep(1);
    int client_fd = connect_client( SERVER_ADDRESS, SERVER_PORT );

    printf("Client closing its fd... ");
    myfail_unless( 0 == close( client_fd ), "close failed" );
    fprintf(stdout, "Client exiting.\n");
    exit(0);
}


int init_server( struct sockaddr * saddr, socklen_t saddr_len )
{
    int sock_fd;

    sock_fd = socket( saddr->sa_family, SOCK_STREAM, 0 );
    if ( sock_fd < 0 ){
        return sock_fd;
    }

    myfail_unless( bind( sock_fd, saddr, saddr_len ) == 0, "Failed to bind." );
    return sock_fd;
}

int start_server( const char * addr, int port )
{
    struct addrinfo *ailist, *aip;
    struct addrinfo hint;
    int sock_fd;

    memset( &hint, '\0', sizeof( struct addrinfo ) );
    hint.ai_socktype = SOCK_STREAM;
    myfail_if( getaddrinfo( addr, NULL, &hint, &ailist ) != 0, "getaddrinfo failed." );

    for( aip = ailist; aip; aip = aip->ai_next ){
        ((struct sockaddr_in *)aip->ai_addr)->sin_port = htons( port );
        sock_fd = init_server( aip->ai_addr, aip->ai_addrlen );
        if ( sock_fd > 0 ){
            break;
        } 
    }
    freeaddrinfo( aip );

    myfail_unless( listen( sock_fd, 2 ) == 0, "Failed to listen" );
    return sock_fd;
}


int server_accept( int server_fd )
{
    printf("Accepting\n");
    int client_fd = accept( server_fd, NULL, NULL );
    myfail_unless( client_fd > 0, "Failed to accept" );
    return client_fd;
}


void server() {
    int server_fd = start_server(SERVER_ADDRESS, SERVER_PORT);
    int client_fd = server_accept( server_fd );

    printf("Server sleeping\n");
    sleep(60);

    printf( "Errno before: %s\n", strerror( errno ) );
    printf( "Write result: %d\n", write( client_fd, "123", 3 ) );
    printf( "Errno after:  %s\n", strerror( errno ) );

    close( client_fd );
}


int main(void){
    pid_t clientpid;
    pid_t serverpid;

    clientpid = fork();

    if ( clientpid == 0 ) {
        client();
    } else {
        serverpid = fork();

        if ( serverpid == 0 ) {
            server();
        }
        else {
            int clientstatus;
            int serverstatus;

            waitpid( clientpid, &clientstatus, 0 );
            waitpid( serverpid, &serverstatus, 0 );

            printf( "Client status is %d, server status is %d\n", 
                    clientstatus, serverstatus );
        }
    }

    return 0;
}
clinuxsocketstcpglibc
22
regularfry

これは、LinuxのmanページがwriteとEPIPEについて述べていることです。

   EPIPE  fd is connected to a pipe or socket whose reading end is closed.
          When this happens the writing process will also receive  a  SIG-
          PIPE  signal.  (Thus, the write return value is seen only if the
          program catches, blocks or ignores this signal.)

Linuxがpipeまたはsocketpairを使用している場合、これらの2つのプログラムが示すように、ペアのreading endを確認できます。

void test_socketpair () {
    int pair[2];
    socketpair(PF_LOCAL, SOCK_STREAM, 0, pair);
    close(pair[0]);
    if (send(pair[1], "a", 1, MSG_NOSIGNAL) < 0) perror("send");
}

void test_pipe () {
    int pair[2];
    pipe(pair);
    close(pair[0]);
    signal(SIGPIPE, SIG_IGN);
    if (write(pair[1], "a", 1) < 0) perror("send");
    signal(SIGPIPE, SIG_DFL);
}

Linuxはそうすることができます。なぜなら、カーネルはパイプまたは接続されたペアのもう一方の端についての生得的な知識を持っているからです。ただし、connectを使用する場合、ソケットに関する状態はプロトコルスタックによって維持されます。テストはこの動作を示していますが、以下は、上記の2つのテストと同様に、すべてを1つのスレッドで実行するプログラムです。

int a_sock = socket(PF_INET, SOCK_STREAM, 0);
const int one = 1;
setsockopt(a_sock, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one));
struct sockaddr_in a_sin = {0};
a_sin.sin_port = htons(4321);
a_sin.sin_family = AF_INET;
a_sin.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
bind(a_sock, (struct sockaddr *)&a_sin, sizeof(a_sin));
listen(a_sock, 1);
int c_sock = socket(PF_INET, SOCK_STREAM, 0);
fcntl(c_sock, F_SETFL, fcntl(c_sock, F_GETFL, 0)|O_NONBLOCK);
connect(c_sock, (struct sockaddr *)&a_sin, sizeof(a_sin));
fcntl(c_sock, F_SETFL, fcntl(c_sock, F_GETFL, 0)&~O_NONBLOCK);
struct sockaddr_in s_sin = {0};
socklen_t s_sinlen = sizeof(s_sin);
int s_sock = accept(a_sock, (struct sockaddr *)&s_sin, &s_sinlen);
struct pollfd c_pfd = { c_sock, POLLOUT, 0 };
if (poll(&c_pfd, 1, -1) != 1) perror("poll");
int erropt = -1;
socklen_t errlen = sizeof(erropt);
getsockopt(c_sock, SOL_SOCKET, SO_ERROR, &erropt, &errlen);
if (erropt != 0) { errno = erropt; perror("connect"); }
puts("P|Recv-Q|Send-Q|Local Address|Foreign Address|State|");
char cmd[256];
snprintf(cmd, sizeof(cmd), "netstat -tn | grep ':%hu ' | sed 's/  */|/g'",
         ntohs(s_sin.sin_port));
puts("before close on client"); system(cmd);
close(c_sock);
puts("after close on client"); system(cmd);
if (send(s_sock, "a", 1, MSG_NOSIGNAL) < 0) perror("send");
puts("after send on server"); system(cmd);
puts("end of test");
sleep(5);

上記のプログラムを実行すると、次のような出力が得られます。

P|Recv-Q|Send-Q|Local Address|Foreign Address|State|
before close on client
tcp|0|0|127.0.0.1:35790|127.0.0.1:4321|ESTABLISHED|
tcp|0|0|127.0.0.1:4321|127.0.0.1:35790|ESTABLISHED|
after close on client
tcp|0|0|127.0.0.1:35790|127.0.0.1:4321|FIN_WAIT2|
tcp|1|0|127.0.0.1:4321|127.0.0.1:35790|CLOSE_WAIT|
after send on server
end of test

これは、ソケットがwrite状態に移行するのに1CLOSEDかかったことを示しています。これが発生した理由を確認するには、トランザクションのTCPダンプが役立ちます。

16:45:28 127.0.0.1 > 127.0.0.1
 .809578 IP .35790 > .4321: S 1062313174:1062313174(0) win 32792 <mss 16396,sackOK,timestamp 3915671437 0,nop,wscale 7>
 .809715 IP .4321 > .35790: S 1068622806:1068622806(0) ack 1062313175 win 32768 <mss 16396,sackOK,timestamp 3915671437 3915671437,nop,wscale 7>
 .809583 IP .35790 > .4321: . ack 1 win 257 <nop,nop,timestamp 3915671437 3915671437>
 .840364 IP .35790 > .4321: F 1:1(0) ack 1 win 257 <nop,nop,timestamp 3915671468 3915671437>
 .841170 IP .4321 > .35790: . ack 2 win 256 <nop,nop,timestamp 3915671469 3915671468>
 .865792 IP .4321 > .35790: P 1:2(1) ack 2 win 256 <nop,nop,timestamp 3915671493 3915671468>
 .865809 IP .35790 > .4321: R 1062313176:1062313176(0) win 0

最初の3行は、3ウェイハンドシェイクを表しています。 4行目はクライアントがサーバーに送信するFINパケットで、5行目はサーバーからのACKであり、受信を確認します。 6行目は、Pushフラグが設定された状態で1バイトのデータをクライアントに送信しようとしているサーバーです。最後の行はクライアントのRESETパケットです。これにより、接続のTCP状態が解放され、3番目のnetstatコマンドが実行されなかった理由です。上記のテストの出力で。

したがって、サーバーは、クライアントがデータを送信しようとするまで、クライアントが接続をリセットすることを知りません。リセットの理由は、クライアントが他のものではなくcloseを呼び出したためです。

サーバーは、クライアントが実際に発行したシステムコールを確実に知ることができず、TCP状態に従うことしかできません。たとえば、close呼び出しを次の呼び出しに置き換えることができます。代わりにshutdown。

//close(c_sock);
shutdown(c_sock, SHUT_WR);

shutdownとcloseの違いは、shutdownは接続の状態のみを管理し、closeはファイル）の状態も管理することです。記述子ソケットを表します。 shutdownはソケットをcloseしません。

shutdownの変更により、出力は異なります。

P|Recv-Q|Send-Q|Local Address|Foreign Address|State|
before close on client
tcp|0|0|127.0.0.1:4321|127.0.0.1:56355|ESTABLISHED|
tcp|0|0|127.0.0.1:56355|127.0.0.1:4321|ESTABLISHED|
after close on client
tcp|1|0|127.0.0.1:4321|127.0.0.1:56355|CLOSE_WAIT|
tcp|0|0|127.0.0.1:56355|127.0.0.1:4321|FIN_WAIT2|
after send on server
tcp|1|0|127.0.0.1:4321|127.0.0.1:56355|CLOSE_WAIT|
tcp|1|0|127.0.0.1:56355|127.0.0.1:4321|FIN_WAIT2|
end of test

TCPダンプは、別の何かも表示します。

17:09:18 127.0.0.1 > 127.0.0.1
 .722520 IP .56355 > .4321: S 2558095134:2558095134(0) win 32792 <mss 16396,sackOK,timestamp 3917101399 0,nop,wscale 7>
 .722594 IP .4321 > .56355: S 2563862019:2563862019(0) ack 2558095135 win 32768 <mss 16396,sackOK,timestamp 3917101399 3917101399,nop,wscale 7>
 .722615 IP .56355 > .4321: . ack 1 win 257 <nop,nop,timestamp 3917101399 3917101399>
 .748838 IP .56355 > .4321: F 1:1(0) ack 1 win 257 <nop,nop,timestamp 3917101425 3917101399>
 .748956 IP .4321 > .56355: . ack 2 win 256 <nop,nop,timestamp 3917101426 3917101425>
 .764894 IP .4321 > .56355: P 1:2(1) ack 2 win 256 <nop,nop,timestamp 3917101442 3917101425>
 .764903 IP .56355 > .4321: . ack 2 win 257 <nop,nop,timestamp 3917101442 3917101442>
17:09:23
 .786921 IP .56355 > .4321: R 2:2(0) ack 2 win 257 <nop,nop,timestamp 3917106464 3917101442>

最後のリセットは、最後のACKパケットの5秒後に行われることに注意してください。このリセットは、ソケットを適切に閉じずにプログラムをシャットダウンしたことが原因です。以前とは異なるのは、リセット前のクライアントからサーバーへのACKパケットです。これは、クライアントがcloseを使用しなかったことを示しています。 TCPでは、FIN表示は、送信するデータがなくなったことを示しています。ただし、TCP接続は双方向であるため、FINを受信するサーバーは、クライアントが引き続きデータを受信できると想定します。上記の場合、クライアントは実際にはデータ。

クライアントがcloseまたはSHUT_WRを使用してFINを発行するかどうかにかかわらず、どちらの場合でも、読み取り可能なイベントをサーバーソケットでポーリングすることにより、FINの到着を検出できます。 readを呼び出した後、結果が0である場合、FINが到着したことがわかり、その情報を使用して必要な操作を実行できます。

struct pollfd s_pfd = { s_sock, POLLIN|POLLOUT, 0 };
if (poll(&s_pfd, 1, -1) != 1) perror("poll");
if (s_pfd.revents|POLLIN) {
    char c;
    int r;
    while ((r = recv(s_sock, &c, 1, MSG_DONTWAIT)) == 1) {}
    if (r == 0) { /*...FIN received...*/ }
    else if (errno == EAGAIN) { /*...no more data to read for now...*/ }
    else { /*...some other error...*/ perror("recv"); }
}

さて、サーバーが書き込みを試みる前にSHUT_WRをshutdownで発行すると、実際にはEPIPEエラーが発生することは明らかです。

shutdown(s_sock, SHUT_WR);
if (send(s_sock, "a", 1, MSG_NOSIGNAL) < 0) perror("send");

代わりに、クライアントにサーバーへの即時リセットを表示させたい場合は、lingerオプションを有効にして、ほとんどのTCPスタックで、前に0のlingerタイムアウトを指定して強制的にリセットすることができます。 closeを呼び出します。

struct linger lo = { 1, 0 };
setsockopt(c_sock, SOL_SOCKET, SO_LINGER, &lo, sizeof(lo));
close(c_sock);

上記の変更により、プログラムの出力は次のようになります。

P|Recv-Q|Send-Q|Local Address|Foreign Address|State|
before close on client
tcp|0|0|127.0.0.1:35043|127.0.0.1:4321|ESTABLISHED|
tcp|0|0|127.0.0.1:4321|127.0.0.1:35043|ESTABLISHED|
after close on client
send: Connection reset by peer
after send on server
end of test

この場合、sendはすぐにエラーになりますが、EPIPEではなく、ECONNRESETです。 TCPダンプはこれも反映しています：

17:44:21 127.0.0.1 > 127.0.0.1
 .662163 IP .35043 > .4321: S 498617888:498617888(0) win 32792 <mss 16396,sackOK,timestamp 3919204411 0,nop,wscale 7>
 .662176 IP .4321 > .35043: S 497680435:497680435(0) ack 498617889 win 32768 <mss 16396,sackOK,timestamp 3919204411 3919204411,nop,wscale 7>
 .662184 IP .35043 > .4321: . ack 1 win 257 <nop,nop,timestamp 3919204411 3919204411>
 .691207 IP .35043 > .4321: R 1:1(0) ack 1 win 257 <nop,nop,timestamp 3919204440 3919204411>

RESETパケットは、3ウェイハンドシェイクの完了直後に送信されます。ただし、このオプションを使用すると危険が伴います。 RESETが到着したときに、もう一方の端のソケットバッファーに未読データがある場合、そのデータはパージされ、データが失われます。 RESETを強制的に送信することは、通常、要求/応答スタイルのプロトコルで使用されます。リクエストの送信者は、リクエストへの応答全体を受信したときにデータが失われることはないことを知ることができます。次に、リクエストの送信者が接続でRESETを強制的に送信するのは安全です。

39
jxh

クライアント用とサーバー用の2つのソケットがあります。これで、クライアントはアクティブなクローズを実行しています。これは、TCPの接続終了がクライアントによって開始されたことを意味します（tcp FINセグメントがクライアントの送信から送信されました）。

この段階で、クライアントソケットがFIN_WAIT1状態になっていることがわかります。ここで、サーバーソケットの状態はどうなっていますか？ CLOSE_WAIT状態であるため、サーバーソケットは閉じられていません。

サーバーからのFINはまだ送信されていません。 （理由-アプリケーションがソケットを閉じていないため）。この段階では、サーバーソケットを上書きしているため、エラーは発生しません。

エラーを確認したい場合は、ソケットに書き込む前にclose（client_fd）と書き込んでください。

close(client_fd);
printf( "Write result: %d\n", write( client_fd, "123", 3 ) );

ここでは、サーバーソケットがCLOSE_WAIT状態ではなくなっているため、writeの戻り値が-veであり、エラーを示していることがわかります。これが明確になることを願っています。

3
Tanmoy Bandyopadhyay

クライアントがソケットをwrite() edした後、（例にコード化されているように）close()を（最初に）1回呼び出した後、次の呼び出しで、予期されるEPIPEとSIGPIPEを取得します。書く（）。

別のwrite（）を追加して、エラーを引き起こしてみてください。

_...
printf( "Errno before: %s\n", strerror( errno ) );
printf( "Write result: %d\n", write( client_fd, "123", 3 ) );
printf( "Errno after:  %s\n", strerror( errno ) );

printf( "Errno before: %s\n", strerror( errno ) );
printf( "Write result: %d\n", write( client_fd, "A", 1 ) );
printf( "Errno after:  %s\n", strerror( errno ) );
...
_

出力は次のようになります。

_Accepting
Server sleeping
Client closing its fd... Client exiting.
Errno before: Success
Write result: 3
Errno after:  Success
Errno before: Success
Client status is 0, server status is 13
_

printf()の2回目の呼び出しによってSIGPIPEが発生したためにプロセスが終了したため、最後の2つのwrite() sの出力が欠落しています。プロセスの終了を回避するために、プロセスにSIGPIPEを無視させることができます。

2
alk

TCPスタックが送信の失敗を検出し、再送信を試みていることに遭遇していると思います。その後のwrite()の呼び出しはサイレントに失敗しますか？つまり、5回書き込んでみてください。閉じたソケットに移動して、最終的にSIGPIPEを取得するかどうかを確認します。「成功」と言うと、3の結果が返されますか？

0
David G

何が起こっているのかは、サーバー側のソケットがまだ有効であるため、TCPセッションが閉じた状態であっても、書き込み呼び出しがファイル記述子への書き込みを有効に試行していると思われます。完全に間違っている私に知らせてください。

0
Eric Y