Skip to main content

Interprocess Communication or IPC, Message Queue

Unix에서의 interporcess의 통신에는
여러가지가 있다.

그 대표적인 것으로,
pipes or FIFOS,
message queues
semaphores
shared memory
sockets
streams이 있다.

그 중에서 Message Queues에 대해서 알아보자


ipcs -q로, kernel에 존재하는 Message Queues를 확인할 수 있다.

msgget으로 새로운 큐가 생성되거나, 존재하는 큐를 획득할 수 있다.
msgsnd로 의해 발생한 새로운 메세지는 queue의 끝에 추가된다
msgrcv로 의해 메세지를 first-in, first-out order로 fetch된다.

MSGMAX, 2048bytes the size of the largest message.
MSGMNB, 4096bytes the maximum size of a particular queue
MSGMNI, 50 the maximum number of messages queues.
MSGTQL, 40 the maximum number of messages

Initialising the Message Queue


#include &lt sys/types.h &gt
#include &lt sys/ipc.h&gt
#include &lt sys/msg.h&gt

int msgget(key_t key, int msgflag);

msgflag는 octal integer이고 Queue's permission and control flags이다
IPC_CREAT
IPC_EXCL
만 사용가능
IPC_EXCL지정후, IPC structure가 이미 존재할 경우, EEXIST에러발생


msgget
실패시, -1
성공시, nonnegative message queue ID

이 id는 다른 함수에서 사용할 수 있다.

send쪽에서는 msgget(key, IPC_CREAT | 0666);으로 하고
recv쪽에서는 msgget(key, 0666)으로 한다.

그리고, send를 하면, kernel의 message queue에 메세지로 저장되고,
그 메세지를 msgrcv로 얻어온다.


Controlling message queues

msgctl(int msqid, int cmd, struct msqid_ds *buf)

cmd
IPC_STAT; 큐의 속성을 msqid_ds struct로 적용
IPC_SET; msg_perm.uid, msg_perm.gid, msg_perm.mod, msg_qbytes의 속성만 변경
단 실행하는 user id가 msg_perm.cuid, msg_perm.uid와 동일할때만 적용됨
IPC_RMID; message queue를 삭제,
단 실행하는 user id가 msg_perm.cuid, msg_perm.uid와 동일할때만 적용됨

Sending and Receiving Messages

msgsnd(int msqid, const void *ptr, size_t nbytes, int flag);
msgsnd에 의해 메세지를 message queue에 놓인다

ptr coontains the positive integer message type, and it is immediately followed by the message data.

struct mymesg{
long mtype; // positive message type
char mtext[512]; // message data, of length nbytes
};

flag는 IPC_NOWAIT
만약, queue가 full일 경우, EAGAIN이라는 에러를 발생시키고.

msgrcv에서
flag를 IPC_NOWAIT로 할 경우, message를 기다리지 않는다.
그러나, 0으로 설정할 경우, 만약 queue에 message를 없을 경우, message를 기다린다.

msgsnd에서는 IPC_NOWAIT로 하나 0으로 하나 변화없음.


msgrcv(int msqid, void *ptr, size_t nbytes, long type, int flag);

msgrcv; retrieve messages from a queue
성공시 size of data portion of message
실패시, -1
type ==0 the first message on the queue is returned. (first-in, first-out)
type > 0 the first message on the queue whose message type equals type is returned.
type < 0 the first message on the queue whose message type is the lowest value less than or equal to the absolute value of type is returned.

Comments

Popular posts from this blog

Linux Resources Monitoring

dstat Requirements:python Dstat is a versatile replacement for iostat, vmstat and ifstat http://linux.softpedia.com/get/System/Diagnostics/Dstat-1401.shtml  - download the source file  - tar -xvjf dstate-0.7.2.tar.bz2  - cd dstate-0.7.2  - sudo make install 사용법 dstat -cdngys --top-io-adv --top-bio-adv 창넓이가 크면 dstat -cdngys --top-io --top-bio dstat 기본옵션은 -cdngy 2. pktstat requirements: libpcap-devel, ncurses-devel pktstat man page 사용법:sudo pktstat -i eth0 -T -l 실행결과 interface: eth0    total: 43.9Mb (3s) cur: 12.3M (78%) min: 12.3M max: 15.8M avg: 14.5M bps    bps    %      b desc   1.4k   0%   4.3k arp  591.8   0%   1.2k ip proto 88 55.101.66.3 <-> igrp-routers  91.3k   0%  91.3k tcp a100236:4478 <-> console:ssh  42.6k   0% 216.4k tcp a100390:mailprox <-> console:ssh   1.1k   0%   ...

nginx로 다중 포트 설정 및 다중 react app 설정

nginx에 다중 포트 설정하기 react로 여러 webapp를 개발하고, 동일한 서버에 실행시킬 필요가 있다. 이때 간단히 nginx에서 다중포트로 여러 webapp를 동일한 서버에서 실행시킬 수 있다. /etc/nginx/sites-available/에 default 파일이 있다. 보통 port 80로 설정되어 있다. 이 파일을 복사해서 sub로 명명한다.   아래와 같이 포트 8080으로 정하고, react app를 build한 디렉터리를 root <dir>로 지정하고, $> sudo service nginx restart 하면 된다. $>sudo systemctl status nginx.service 로 nginx 상태 확인이 가능하면, $> netstat -ano | grep 8080 으로 8080 포트가 살아있는 또는 외부PC에서  $>telnet ip 8080으로 telnet 접속이 되는지 확인하면 된다. 종종 Nginx 500 Interval Server Error가 발생하는데, 이는 1) root <dir>에서 <dir> 주소가 정확하지 않거나, 2) 파일 권한이 없거나이다. chmod 755 <dir>하면 대부분 해결될 것이다. 그럼 오늘도 유익한 하루 되시길..   

SDN(OpenFlow) 개요

OpenFlow는 SDN(Software Defined Network)의 하나의 콤포넌트이다. 아래는 2013/3/13 오픈프로우 코리아 주최로 열린 한국 SDN Interest Group 4번째 정기세미나의 내용이다. 다음에는 꼭 모임에 참석하고 싶다. SDN Architecture including OpenFlow 위 그림에서와 같이, Control Layer부분과 Application Layer부분이 최근 활발히 연구개발되고 있다. 그 중 Control Layer부분은 Controller가 많은 비중을 차지 하는데, 다음 절에서와 같이 이미 많은 벤더들이 많은 OpenFlow 기반의 Controller를 제공하고 있다. 그외 소규모 벤더들은 Controller가 아닌 Application Layer에서 보안, 로드벨런싱, 홈네트워크 등의 서비스가 지원되는 제품 개발에 힘쓰고 있다. SDN에서는 Router라는 명칭 대신, Switch라는 명칭을 사용하는데, 이는 Router보다 더 단순한 기능을 수행하고, 기존 레거시와 차별화를 위해 명명된 것으로 보인다. 또한, Switch를 반드시 벤더로부터 구매할 필요가 없다. 상황에 따라 리눅스 등의 운영체제를 기반으로 자체 개발이 가능하다. Controllers의 종류 SDN의 Controller 가운데 Open Source로 운영되는 것은 다음과 같다. 대부분 Java언어로 구현되어 있다. 따라서 플랫폼 또는 인프라 개발자라면 Java에 능숙해야 한다. NOX C++/Python Beacon Java Floodlight Java Maestro Java RouteFlow NOX, Quagga 보안을 위한 Open Source FortNOX Java 기반의 SE-FloodLight  공격 감지  인증  스위치의 Flow 처리 성능 고려 FRESCO OpenFlow Contro...