[문의] 리눅스에서의 시리얼 통신 프로그래밍 관련하여 고수님들의 따뜻한 손길 기다립니다.
안녕하세요!~
리눅스 초짜입니다 ㅜㅡ
현재 임베디드 SW 공모전을 준비하고 있는 학생입니다 ^^;
지금 시리얼 통신 부분을 공부하고 있습니다.
HOW-To 문서를 통해서 Canonical 입력 처리 방식과 non-Canonical 입력 처리 방식으로 모두 프로그램을 짜보았습니다.
테스트해보니 모두 잘 되네요.
그런데 제가 궁금한 점은 말입니다~ ^^;
Window 환경에서의 시리얼 통신과 좀 다르다는 것을 느끼면서 생긴 궁금점 입니다.
Window 에서는 open -> read / write 방식을 사용했었습니다. 물론 리눅스도 같지요.
그러나 window 에서의 read 는 이미 도착해 있는 수신된 메시지들을 시스템 큐로 부터 읽어오는 것으로 알고 있습니다.
반면 linux 에서는 read 호출 시 Canonical의 경우에는 read 될 때까지 block 이 되고
non-canonical 의 경우에는 시간이나 최소 읽은 byte 수의 설정에 따라 수신된 메시지를 읽는 것 같습니다.
window 처럼 동작 되려면 제가 직접 큐를 만들어서 구현해야 되는 것인지 궁금하네요...
아니면 제가 생각하고 있는 window 와 linux 에서의 수신된 메시지들을 읽는 절차가 잘못 된 것인지 궁금하구요...
고수님들의 따쓰한 답변을 저녁먹으며 기다려보겠습니다 ^^;;
날씨가 덥고 습하지만 짜증내지 마시고~ 즐거운 하루 되세요!~~
select()나 glib에서
non-block모드로 연 후, select()나 glib에서 제공하는 giochannel을 사용하세요.
----
Do not feed troll!
----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러
파악하신 것처럼
파악하신 것처럼 리눅스나 윈도 모두 기본적인 방식은 비슷합니다.
약간의 차이가 있어보이긴 하지만, 리눅스쪽에도 내부 버퍼가 없는 것은 아니구요. 지정된 크기만큼 읽혀지기 전까지 대기하도록 돼 있으니까요.
방식의 차이가 일부 있어도, 실제 응용 프로그램 개발시에는 리눅스나 윈도 모두 입력 큐 구현이 필수적이게 돼 있습니다. 시리얼 통신을 하든 소켓 통신을 하든 보낸 즉시 보낸만큼 받아지는 것이 아니니까요.
윈도라고 해서 입력 큐 없이 원활한 통신이 가능하던가요? 제 경험상으로는 그렇지 않던데요...
Orion Project : http://orionids.org
답변 두분 모두 감사합니다 ^^
제가 test 프로그램을 잘못 생각했었네요 ^^;
체스맨님 말씀처럼 내부버퍼가 존재하군요 ^^;;
예전 윈도우 응용 짤때도 궁금한 것이었는데요,
체스맨님 말씀처럼 내부버퍼 -> 응용을 짜면서 구현한 큐 -> read 의 과정과
내부버퍼 -> read 로 큐를 거치지 않고 바로 읽는 방법에 차이가 존재하는 건가요?
예전 윈도우 응용 짤때 별차이 없다라는 생각이 들어서 큐를 거치지 않고 필요할 때마다 read 를 통해서 필요한 만큼만 내부버퍼에서 읽어들였었거든요...
큐를 거치는 경우는
큐를 거치는 경우는 현재 필요한 만큼만 읽을 크기를 지정하지 않고, 준비된 버퍼 크기만큼 읽을 크기를 지정합니다.
그리고, 지정된 크기보다 적게 읽혀도 리턴을 하게 되고, 다시 커널에 읽기 요청을 하게 됩니다.
읽힌 크기에 무관하게, 읽은 만큼 큐에 넣고 패킷이 완성되면 처리하므로, 통신 스레드가 입력 대기에 의해 블럭되지 않아도 됩니다. 그러므로 비동기 입출력에 유리하고, 대량의 데이터가 전달되는 경우 커널의 내부 버퍼가 오버플로 되는 상황에서 벗어날 수 있습니다.
그래서 큐가 없이 필요한 만큼만 읽어 처리하는 경우는 간단한 데이터 통신 규약이 아니면 적용하기 힘듭니다. 상호간에 데이터를 빈번하게 주고 받는 복잡한 통신 프로토콜에서는 입력 큐와 비동기 입출력이 필수입니다.
Orion Project : http://orionids.org
답변 정말 감사합니다!!
이해가 될것 같습니다 ^^;
즐거운 주말 되세요!!! ^_______________________^
댓글 달기