리눅스 소켓과 양말 구조의 차이점

//***************************************** *********************************

/* 1. 열려 있는 모든 파일, 소켓 및 등등은 파일 데이터 구조로 표시되므로 파일과 소켓은 inode-gt;u(union)의 각 멤버로 구분됩니다.

struct inode {

.. ...........

union {

struct ext2_inode_info ext2_i

struct ext3_inode_info ext3_i ; 소켓 소켓_i;

................................

} u; ;

2. 각 소켓 데이터 구조에는 sock 데이터 구조 멤버가 있습니다. 이 두 개는 소켓의 확장입니다. gt.;socket

해당 소켓을 가리킵니다.

3. 소켓과 sock은 두 데이터 구조를 하나로 병합하는 것이 좋습니다. 이는 소켓이 inode 구조의 일부이기 때문입니다. 즉, inode 구조 내부의 공용체가 소켓 구조로 사용되기 때문입니다.

소켓 작업의 특수성으로 인해 이 데이터 구조에는 많은 수의 구조적 구성 요소가 필요합니다. 이러한 구성 요소가 모두 소켓

구조에 배치되면 inode 구조의 결합이 매우 커집니다. 결과적으로 inode 구조도 매우 커지며, 다른 파일 시스템의 경우 공용체는 그렇게 클 필요가 없습니다.

따라서 시스템에서 사용되는 inode 구조의 수가 엄청납니다. 그 수가 소켓보다 훨씬 많기 때문에 해결 방법은 소켓을 두 부분으로 나누어 파일 시스템과 밀접한 부분을 소켓 구조에 넣고, 통신과 밀접한 부분을 별도의 구조인 sock에 넣는 것입니다. ;

*/

struct 소켓

{

socket_state state; // 이 상태는 소켓의 현재 상태를 나타내는 데 사용됩니다. 소켓

p>

typedef enum {

SS_FREE = 0, /* 할당되지 않음 */

SS_UNCONNECTED, /* 소켓에 연결되지 않음 */

SS_CONNECTING , /* 연결 중 */

SS_CONNECTED, /* 소켓에 연결됨 */

SS_DISCONNECTING /* 연결 해제 중 */

} 소켓_상태 ;

unsigned long flags; //이 멤버의 가능한 값은 다음과 같습니다. 이 플래그는 소켓 사용 여부를 설정하는 데 사용됩니다.

#define SOCK_ASYNC_NOSPACE 0

#define SOCK_ASYNC_WAITDATA 1

#define SOCK_NOSPACE 2

struct proto_ops *ops; 프로토콜에 따른 소켓의 프로토콜 패밀리(예: IPv4 TCP는 inet_stream_ops)

struct inode *inode; //소켓이 속한 inode를 나타냅니다.

struct fasync_struct *fasync_list ; //비동기 웨이크업 큐

struct file *file; / /file 백 포인터

struct sock *sk; //sock 포인터

wait_queue_head_t wait ; //sock의 대기 큐, TCP가 대기해야 할 때 이 큐에서 휴면

Short type; //SOCK_STREAM과 같은 특정 프로토콜 계열의 소켓 유형을 나타냅니다. >unsigned char passcred; //TCP 분석에서 고려할 필요가 없습니다.

};