轉貼部落格

Understanding MPEG-2, MPEG-4, H.264, AVCHD and H.265
By Sareesh Sudhakaran
The full-blown Sony A7s Guide is available right now! Click this to learn more.

UDP SOCKET编程中的connect()

分类： 网络编程2010-01-31 21:12 2840人阅读 评论(0) 收藏 举报

[Linux Socket Programming] UDP Socket Reuse Address


最近因為工作需要，在Linux下需要讓多個UDP socket使用同一個port。本文將透過實驗來觀察多個UDP socket使用同一個port時會發生什麼事。
本文的程式原始碼可在以下網址取得
https://github.com/huangtw/UDPReuseAddrTest
SO_REUSEADDR
在Linux下如果多個socket要bind同一個port，可以用setsocket設定SO_REUSERADDR來達成，而在TCP socket與UDP socket上各有不同的效果。
TCP
在尚未設定SO_REUSERADDR的情況下，當一個TCP socket bind了0.0.0.0:PortA後，則其他Tsocket將無法在bind PortA，因為0.0.0.0代表任何一個interface的IP，因此socket不管綁定哪個IP的PortA都會造成衝突。
此時如果一個socket設定了SO_REUSERADDR，則可以成功bind指定IP的PortA，但是還是不能bind 0.0.0.0:PortA，也就是說在設定了SO_REUSERADDR之後，只有IP一模一樣才會視為衝突，0.0.0.0與特定IP不再視為衝突。
不過有一個例外，當一個TCP socket bind了0.0.0.0:PortA，並且開始listen之後，此時其他TCP socket即使設定了SO_REUSERADDR也無法bind PortA，就算指定特定的IP也一樣。
除了共用port之外，另外一個常見使用情境是，當一個bind了某個port的TCP socket close之後，其他socket並無法馬上bind同一個port，因為TCP socket還處於TIME_WAIE的狀態，尚未真的關掉。此時新的socket如果設定SO_REUSERADDR，則可以成功bind同一個port。
UDP
在UDP與TCP不太一樣，只要每個UDP socket都有設定SO_REUSERADDR，則可以綁定一模一樣的IP跟port。在boardcast或者multicast模式下，如果多個UDP綁定同一個IP與port，當有UDP封包送到該IP:port時，每一個socket都會收到一份相同的封包。
如果是unicast呢？網路上似乎很少提到這個狀況，因此我做了一個實驗來確定這件事。
實驗
本實驗需要兩個程式，一邊為傳送端(udp_send)，一邊為接收端(udp_receive)，傳送端每隔固定時間會從IP_A:Port_A向IP_B:Port_B發送UDP封包，而接收端會產生多個UDP socket bind同時bind IP_B:Port_B，觀察哪一個socket能收到封包。
除此之外，接收端的部分UDP socket為connected(指定destination為IP_A:Port_A，只會收到來自IP_A:Port_A的封包，封包也只能傳送給IP_A:Port_A)，來看這種情況下一般UDP socket與connected UDP socket的差異。
udp_send.c

#include <unistd.h>

 #include <stdio.h>

 #include <stdlib.h>

 #include <netdb.h>

 #include <sys/types.h>

 #include <sys/socket.h>

 #include <netinet/in.h>

 #include <arpa/inet.h>

 #include <string.h>

 

 int main(int argc, char* argv[])

 {

 int fd;

 int localPort, peerPort;

 char *peerIP;

 struct sockaddr_in local_addr, peer_addr;

 char buffer[1024];

 

 if (4 != argc)

 {

 exit(1);

 }

 

 localPort = atoi(argv[1]);

 peerIP = argv[2];

 peerPort = atoi(argv[3]);

 

 if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0)

 {

 printf("socket open failed!\n");

 exit(1);

 }

 

 bzero((char *) &local_addr, sizeof(local_addr));

 local_addr.sin_family = AF_INET;

 local_addr.sin_addr.s_addr = ntohl(INADDR_ANY);

 local_addr.sin_port = htons(localPort);

 

 if (bind(fd, (struct sockaddr *)&local_addr, sizeof(local_addr)) < 0)

 {

 printf("bind failed\n");

 }

 

 bzero((char *) &peer_addr, sizeof(peer_addr));

 peer_addr.sin_family = AF_INET;

 peer_addr.sin_addr.s_addr = inet_addr(peerIP);

 peer_addr.sin_port = htons(peerPort);

 

 if (connect(fd , (struct sockaddr *)&peer_addr , sizeof(peer_addr)) < 0)

 {

 printf("udp connect failed!\n");

 exit(1);

 }

 

 int i = 0;

 while(1)

 {

 int size,ss;

 int ssize = 0;

 

 size = sprintf(buffer, "%d\n", i++);

 sleep(2);

 while (ssize < size)

 {

 if ((ss = send(fd, buffer + ssize, size - ssize, 0)) < 0)

 {

 //cout << "send error" << endl;

  printf("send error\n");

 exit(1);

 }

 

 ssize += ss;

 }

 }

 

 return 0;

 }

 

udp_receive.c

#include <stdio.h>

 #include <unistd.h>

 #include <stdlib.h>

 #include <string.h>

 #include <netdb.h>

 #include <sys/types.h>

 #include <sys/socket.h>

 #include <netinet/in.h>

 #include <arpa/inet.h>

 

 int createSocket(int port)

 {

 int fd;

 struct sockaddr_in local_addr;

 

 if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {

 printf("socket open failed!\n");

 exit(1);

 }

 

 int sock_opt = 1;

 if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (void*)&sock_opt, sizeof(sock_opt)) < 0) {

 printf("setsockopt failed!\n");

 exit(1);

 }

 

 bzero((char *) &local_addr, sizeof(local_addr));

 local_addr.sin_family = AF_INET;

 local_addr.sin_addr.s_addr = ntohl(INADDR_ANY);

 local_addr.sin_port = htons(port);

 

 if (bind(fd, (struct sockaddr *)&local_addr, sizeof(local_addr)) < 0)

 {

 printf("bind failed\n");

 }

 

 return fd;

 }

 

 void* worker(void* pfd)

 {

 int fd = *(int*)pfd;

 char buffer[1024];

 

 while (1)

 {

 if (recv(fd, buffer, sizeof(buffer) - 1, 0) < 0)

 {

 printf("udp recv failed!\n");

 exit(1);

 }

 printf("socket %d received: %s\n", fd, buffer);

 //cout << "socket " << fd << " received:" << buffer << endl;

  }

 }

 

 int main(int argc, char* argv[])

 {

 int *pfd, localPort, peerPort;

 char *peerIP;

 char buffer[1024];

 struct sockaddr_in local_addr, peer_addr;

 

 if (4 != argc)

 {

 exit(1);

 }

 

 localPort = atoi(argv[1]);

 peerIP = argv[2];

 peerPort = atoi(argv[3]);

 

 int i = 0;

 while (1)

 {

 pfd = malloc(sizeof(int));

 *pfd = createSocket(localPort);

 printf("socket %d opened\n", *pfd);

 

 if ((i >= 3) && (i < 6))

 {

 bzero((char *) &peer_addr, sizeof(peer_addr));

 peer_addr.sin_family = AF_INET;

 peer_addr.sin_addr.s_addr = inet_addr(peerIP);

 peer_addr.sin_port = htons(peerPort);

 

 if (connect(*pfd , (struct sockaddr *)&peer_addr , sizeof(peer_addr)) < 0)

 {

 printf("udp connect failed!\n");

 exit(1);

 }

 }

 

 pthread_t workerThread;

 pthread_create(&workerThread, NULL, worker, pfd);

 pthread_detach(workerThread);

 getchar();

 i++;

 }

 

 return 0;

 }

 

在udp_receive中，每按一次按鍵，就會產生bind同一組IP與port的socket，而第4~6個socket還會connect到傳送端的IP跟port，引此能比較出一般UDP socket與connetec UDP的差別

執行結果

上圖為接收端的執行畫面，接收端的UDP socket會bind 127.0.0.1:5555，傳送端則綁定127.0.0.1:6666。
可以看到前六個socket依序產生的過程中，只有最後一個bind的socket才會收到封包，但是第七個socket(socket 9)，最後產生
卻收不到封包，仍然是第六個socket(socket 8)收到封包。
從這個結果可以知道，如果多個socket綁定同樣的IP跟port，connect到封包來源IP:port的connected UDP socket可以優先接收，如果有多個socket滿足這個條件，則最晚bind的connected UDP socket可以收到封包。如果沒有connected UDP socket，則最晚bind的一般UDP socket可以收到封包。

 
正确使用#include和前置声明(forward declaration)

分类： 杂谈2006-07-23 22:21 17664人阅读 评论(6) 收藏 举报

forward declaration
 
一個小技巧，說真的，在我得知這個技巧時還蠻驚訝的 :P
驚訝之餘也感嘆自己見識太少與能力不足，
竟然有如此巧妙的技巧可以取代我一直覺得理所當然的事，

原文於此：Use forward declaration when possible
大概就是說若你要創造一個名為 B 的類別時，它有個成員為 A 類別的指標，
這種情況我們通常會在 B.h 的上端寫一句 #include "A.h"
這並沒有不對的地方，但當我們更動了 A.h 檔時，
 Compiler 在編譯的時後會重編所有 include A.h 的檔案，這當然包括 Class B
這時我們可以使用 froward declaration 的技巧取代 #include "A.h" 這行指令，
移除該行 include 命令，並在 Class B 的前面事先宣告 Class A;
class A;
class B
{
private:
  A* fPtrA ;
  // 或是連類別 A 一起宣告 class A* fPtrA; 就可以連上面的 class A; 也省略
public:
  void mymethod(const& A) const ;
};
如此可以縮短專案建置的時間，但這有個需要注意的重點，
此處我們只有宣告 Class A 讓編譯 B 時不發生錯誤，A 類別的實際大小並不知道，
所以我們只能在宣告成員變數為 reference 或 pointer 才可以使用這個技巧，
就如同上例 fPtrA 是一個位址，mymethod 所用的參數是一個 reference
因為指標的容量是視你的作業系統為 x86 或 x64 而固定的，沒有例外，
當我們使用其他類別是必須採用繼承或宣告為一個實體時，無可選擇還是要用 include
以下是兩個簡單的例子與說明。
任何種類的繼承需要明確的類別
#include <A.h>
class B : public A
{
};
宣告一個實體 A 而非 Point
因為必須明確的知道 A 類別需要多少記憶體空間而使用 include
#include <A.h>
class C
{
private:
  A fA;
public:
  void mymethod(A par);
}
知道這個眉角是一回事，若問我以後會不會這麼做？答案是，不會…
畢竟一個專案不可能永遠都是自己開發，自己維護，若今天自己很確定的宣告了指標變數，
幾個月後接手的人為了擴充功能而必須改為實體變數，豈不是增加困擾，
再者編譯時間是開發人員成本，不是使用者成本，在 daily build 的環境下成本又變得更不重要，
所以還是尊守老傳統乖乖的寫下明確的 include 指令，又 Class 又 include 的擠在一起也不好看

C/C++之指標 (pointer)，參考 (reference) 觀念整理與常見問題 (轉貼)
   

 

[C/C++] 千萬別把function definition & 變數definition寫入.h裡
2792007張貼者： Falldog標籤： 程式設計

[Linux c] 防止 zombie 程序產生[转载]
 闷-扪 2011-12-11 20:50:18

 

Digital Certificates
17 out of 25 rated this helpful - Rate this topic

Digital certificates, similar to identification cards, are electronic credentials that are used to certify the online identities of individuals, organizations, and computers. Certificates are issued and certified by CAs. PKIX-compliant public key infrastructures support industry standard X.509 version 3 certificates.

Functions Like a Traditional Identification Card

Digital certificates function similarly to identification cards such as passports and drivers' licenses. Identification cards are issued by recognized government authorities. When someone requests an identification card, a government authority verifies the identity of the requester, certifies that the requester meets all requirements to receive the card, and then issues the card. When an identification card such as a driver's license is presented to others, they can verify the identify of its owner because the card provides the following security benefits:

• 
  

  It contains personal information to help identify and trace the owner.

  
  


• 
  

  It contains the photograph and the signature of the rightful owner to enable positive identification.

  
  


• 
  

  It contains the information that is required to identify and contact the issuing authority.

  
  


• 
  

  It is designed to be tamper resistant and difficult to counterfeit.

  
  


• 
  

  It is issued by an authority that can revoke the identification card at any time (for example, if the card is misused or stolen).

  
  


• 
  

  It can be checked for revocation by contacting the issuing authority.

  
  

Issued by Certification Authorities

Like a driver's license, digital certificates are issued by CAs to provide proof for verifying the identity of online entities. However, instead of containing a photograph and the signature of the certificate's owner, a certificate binds the owner's public key to the owner's private key.

A certificate contains information that identifies the certificate's owner (called the subject) as an entity on the network. A certificate also contains the owner's public key. Furthermore, a certificate identifies the CA (called the issuer) that issued the certificate. A CA uses its private key to digitally sign each certificate it issues. To create the digital signature, the CA generates a message digest from the certificate, encrypts the digest with its private key, and includes the digital signature as part of the certificate. Anyone can use the message digest function and the CA's public key to verify the certificate's integrity. If a certificate becomes corrupted or someone tampers with it, the message digest for the altered certificate does not match the digest in the CA's digital signature. Figure 14.8 shows how a certificate is signed by the issuing CA.

Figure 14.8 Digital Signature for a Certificate

A certificate is public information that is available to anyone. Certificates are commonly distributed by means of directories, public folders, e-mail, and Web pages. Because the certificate owner's public key is contained in a certificate, distributing a certificate also distributes the public key. Others can choose to trust a certificate owner's private key based on the reputation of the CA that issued the certificate and based on confidence in the certificate issuing practices of the CA.

Contents of X.509 Version 3 Certificates

PKIX-compliant public key infrastructures, including the public key infrastructure in Windows 2000, support X.509 version 3 certificates. Figure 14.9 shows the contents of X.509 version 3 certificates.

Figure 14.9 X.509 Version 3 Certificate

The contents of X.509 version 3 certificates are described in Table 14.1.

Table   14.1 Description of X.509 Version   3 Certificate Contents

Certificate Field	Description
Version	Version of the certificate format; for example, version 3.
Certificate Serial Number	The unique serial number that is assigned by the issuing CA. The CA maintains an audit history for each certificate so that certificates can be traced by their serial numbers. Revoked certificates also can be traced by their serial numbers.
Certificate Algorithm Identifier	The public key cryptography and message digest algorithms that are used by the issuing CA to digitally sign the certificate.
Issuer	The name of the issuing CA. The name can be listed in one or more of the following formats: X.500 directory name, Internet e-mail address, fully qualified domain name (FQDN), X.400 e-mail address, and URL.
Validity Period	The certificate's start and expiration dates. These define the interval during which the certificate is valid, although the certificate can be revoked before the designated expiration date.
Subject	The name of the subject (owner) of the certificate. The name can be listed in one or more of the following formats: X.500 directory name, Internet e-mail address, fully qualified domain name (FQDN), X.400 e-mail address, and URL.
Subject Public-Key Information	The public key and a list of the public key cryptography algorithms. The algorithms are for the tasks for which the public key set can be used, such as digital signing, secret key encryption, and authentication.
Issuer Unique Identifier	Optional information for uniquely identifying the issuer, when necessary.
Subject Unique Identifier	Optional information for uniquely identifying the subject, when necessary.
Extensions	Additional information that can be specified for optional use by public key infrastructures. Common extensions include a list of specific uses for certificates (for example, S/MIME secure mail or IPSec authentication), CA trust relationship and hierarchy information, a list of publication points for revocation lists, and a list of additional attributes for the issuer and subject.
Certification Authority's Digital Signature	The CA's digital signature, which is created as the last step in generating the certificate.

Uses of the Public Key and Private Key Set

X.509 version 3 certificates contain information in the Subject Public-Key Information field that specifies the cryptography operations for which the public key and private key set can be used. Public key security systems commonly support the following basic cryptography operations:

• 
  

  Digital signing of electronic data to verify data origin and the integrity of data.

  
  


• 
  

  Authentication of entities that are communicating over networks.

  
  


• 
  

  Secret key encryption to protect symmetric secret encryption transmitted and shared over networks.

  
  

The public key and private key set can be used to provide a variety of specific security functions for information security technologies. These specific functions of certificates are listed in the Extensions field. Common specific security functions for public key technology include the following:

• 
  

  Secure mail to provide authentication, confidentiality, integrity, and nonrepudiation for e-mail communications.

  
  


• 
  

  Secure Web communications to provide authentication, integrity, and confidentiality between Web clients and servers.

  
  


• 
  

  Code signing to provide integrity and nonrepudiation for executable code to be distributed on the Internet or intranets.

  
  


• 
  

  Local network logon or remote access logon to authenticate users of network resources.

  
  


• 
  

  IPSec authentication to authenticate clients that do not use Kerberos authentication or shared secret passwords for IPSec communications.