簡體   English   中英

非阻塞的系統/套接字並發?

[英]Sys/socket concurrency for non-blocking?

我有一個使用 sys/socket 和 OpenSSL 設置的簡單套接字服務器。 對於每個連接,客戶端都需要向服務器發送消息,接收響應,然后回復該響應。

我找不到任何使這些套接字非阻塞的明確機制? 系統必須能夠同時處理多個套接字......

我用於偵聽連接的服務器代碼:

while(1)
{
   struct sockaddr_in addr;
   uint len = sizeof(addr);
   SSL *ssl;            
   int client = accept(sock, (struct sockaddr*)&addr, &len);
   if (client > 0) 
   {
      std::cout<<"Client accepted..."<<std::endl;
   }
   else
   {
      perror("Unable to accept");
      exit(EXIT_FAILURE);
   }

   ssl = SSL_new(ctx); 
   SSL_set_fd(ssl, client);

   if (SSL_accept(ssl) <= 0)
   {
      std::cout<<"ERROR"<<std::endl;
   }
   else
   {
      char buff[1024];
      SSL_read(ssl, buff, 1024);
      std::cout<<buff<<std::endl;

      std::string reply="Thanks from the server";
      char buff_response[1024];
      reply.copy(buff_response, 1024);
      const void *buf=&buff_response;
      SSL_write(ssl, buf, 1024);

      char another_buff[1024];
      SSL_read(ssl,another_buff,1024);
      std::cout<<another_buff<<std::endl;
   }
}

我已經研究過“select()”,但是這似乎不允許並發,但允許系統知道套接字何時被釋放?

有沒有人有解決這個基本問題的經驗?

首先,對於服務器代碼, 區分並發性和並行性很重要。 一個合理的服務器通常會同時處理比其內核數多得多的連接 因此,重要的是使代碼並發,因為它可以(有效地)處理許多並發連接,而​​不依賴於並行性(在每個連接都由一個線程處理的意義上)。

從這個意義上說, select實際上是並發的合理選擇,並且給了你非阻塞的效果

當您的系統同時處理多個套接字時, select指示您可以在哪些套接字上執行諸如sendrecv而不會阻塞。 如果您很好地使用select您將不會遇到線程空閑、無限期等待某些操作繼續進行而其他套接字已准備就緒的情況。

來自 gnu.org最小示例顯示了一個相當高效的服務器,它似乎可以滿足您的需求。

fd_set active_fd_set, read_fd_set;
FD_ZERO (&active_fd_set);
FD_ZERO (&read_fd_set);

// Use FD_SET to add sockets according to what you want to do with them

/* This call (checking to see who can be read) is the 
* only thing that blocks. But if it does, no socket is ready for reading. */
if (select (FD_SETSIZE, &read_fd_set, NULL, NULL, NULL) < 0) {
    // Handle error;

for (i = 0; i < FD_SETSIZE; ++i)
    if (FD_ISSET (i, &read_fd_set))
        // Here you can read without its blocking.

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM