안녕하세요.
인터넷에서 글을 검색해보다가 이경문씨 글을 보게 되어서 이렇게 질문을 남기게 됐습니다.
( http://cafe.naver.com/neteg.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=40206 )
혹시 아신다면 도움좀 부탁드리겠습니다.
질문의 주제는 브로드캐스트에 대한 질문인데요.
자기 자신이 브로드캐스트하는 메시지를 자기 자신이 수신하는 문제를 해결하고 싶습니다.
저는 유선이 아니라 무선에서 작업을 하고 있는데요.
안드로이드 플랫폼에서 공유기가 존재하지 않는 상태에서 디바이스 들끼리 ADHOC 네트워크를 구성했습니다.
그 상태에서 디바이스 한개가 브로드캐스트 하게 되면 나머지 디바이스들이 그것을 수신하는 시스템을 구성하고 있는데요.
문제는 자기 자신이 브로드캐스트하는 메시지를 자기 자신이 계속 받아서 네트워크 쓰루풋이 너무 떨어진다는것입니다.
유니캐스트로 전송했을때는 1.3MBps 정도 나오던것이 브로드캐스트를 하게 되면 0.1MBps 정도로 쓰루풋이 떨어집니다.
저는 자기 자신이 브로드캐스트 한 메시지는 MAC단에서 자기가 알아서 필터링 할줄알았는데 그것이 아니더라구요.
이문제를 해결하고자 몇일째 고생중입니다.
커널에서 iptables 규칙에 자기자신이 보낸 메시지는 차단하도록 방화벽을 설정해도,
네트워크레이어를 거쳐서 시스템커널에서 필터링 되는것이라서 쓰루풋은 여전히 낮게 측정되었습니다.
자기 자신의 브로드캐스트 메시지를 차단할수있는 방법이 있을까요?
도움 부탁드립니다.
감사합니다.
빠른답변 정말 감사드립니다.
이미 어플리케이션 레이어에서 처리하고있는데 브로드캐스팅 밴드위쓰가 너무 떨어져서 사용할수가 없는 수준입니다.
95KB/s 속도가 나오는데요. 이건 해결할수있는 방법이 없다는 말씀이신가요?
제가 브로드캐스트는 답이 안나와서 멀티캐스트로 바꿔서 코딩을 해봤습니다.
MultiSock.setLoopbackMode(true); 멀티캐스트 소켓에서는 루프백 패킷을 받지 않도록 하는 옵션이 있떠라구요.
하지만 위와 같이 설정을해도 여전히 루프백 메시지를 받게 됩니다.
멀티캐스트/브로드캐스트 전부다 답이 없네요 ㅠ,ㅜ
![[Level:16]](http://www.gilgil.net/modules/point/icons/default/16.gif "Point:23265point (7%), Level:16/30"){kind=icon}
gilgil> 이미 어플리케이션 레이어에서 처리하고있는데 브로드캐스팅 밴드위쓰가 너무 떨어져서 사용할수가 없는 수준입니다. 95KB/s 속도가 나오는데요. 이건 해결할수있는 방법이 없다는 말씀이신가요?
이 문제는 L1(layer 1)문제라서 application 차원에서 속도 향상을 기대하기는 힘들 것으로 보입니다. 그런데 UDP 기반에서 95KB/s는 어떻게 구하셨나요?
> 제가 브로드캐스트는 답이 안나와서 멀티캐스트로 바꿔서 코딩을 해봤습니다. MultiSock.setLoopbackMode(true); 멀티캐스트 소켓에서는 루프백 패킷을 받지 않도록 하는 옵션이 있떠라구요. 하지만 위와 같이 설정을해도 여전히 루프백 메시지를 받게 됩니다.
broadcast와 multicast는 로컬 네트워크 환경에서 야기되는 부하의 량도 똑같고, loopback으로 다시 패킷이 수신되는 현상도 똑같습니다. 어쩔 수가 없어요.
먼저 95KB/s 는 그냥 덩치큰 더미 파일 보낸후에 파일 전송 시간으로 평균 쓰루풋을 계싼한 것입니다.
그리고 본문에 말쓰드렸듯이 저는 공유기 스위치와 같은 인프라스트럭쳐를 사용하지않고
순수 단말끼리의 애드혹상태로 네트워크를 구성하였는데요.
제가 의구심이드는것은 무선에서는 어차피 unicast, broadcast, multicast 모두 결국엔 브로드캐스트로 구현될수밖에 없지 않습니까?
결국엔 패킷헤더의 차이밖에 없는것인데, unicast의 경우는 1.3MBps 의 속도가 나오게 됩니다.
결국에 현재 제가 의심하고 있는바는 자기 자신의로 들어오는 패킷 때문에 self-contention이 발생하여 속도가 늦어지는 것이 첫번째구요.
(그러나 속도가 1/10 이하로 떨어진다는게 이상합니다.)
두번째로는 스위치나 공유기에서 브로드캐스트 메시지에 대한 속도제약같은게 있다는 리플을 보았습니다.
혹시 커널에서도 이와 같이 메시지에 대한 레이트 컨트롤을 하도록 되어있는지... (broadcasting strom으로 인한 네트워크 다운 현상을 막기 위해서)
현재는 위 두가지에 대해서 의심을 하고 해결하려고 노력중입니다.
multicast는 스트리밍에 많이 쓰이는 방식인데... 제가 하려는것도 현재 안드로이드 기기로 공유기 없이 스트리밍을 쏴줘서 주변 기기들이 볼수있도록 하고싶은것입니다.
결국엔 한 디바이스가 base station이 되고 나머지가 client가 되서 broadcast 혹은 multicast 되는 스트리밍 데이터를 수신하는것이 최종 목표인데요.
도저히 스트리밍을 할만한 쓰루풋이 나오지 않아서 문제입니다.
또 여기저기 헤메봐야겠네요 ㅠ,ㅜ
많은 도움 주셔서 감사합니다!!!!
해답을 찾은것 같아서 리플을 답니다.
패킷이 루프백으로 들어오긴 하는데 쓰루풋이 급격하게 떨어지는 이유는 그것이 아니였던것 같습니다.
802.11 ad hoc 모드는 11Mbps로 동작하더군요.
이경우 제가 측정한 unicast mode의 1.3MBps하고 거의 비슷한 속도입니다.
그런데 broadcast의 경우에 RTS/CTS를 사용해서 무선채널 시간보장을 받을수 없기 때문에 가장 낮은 모듈레이션스킴인 BPSK를 쓰게되는것 같습니다.
BPSK같은 경우 error에 가장 resilent한 대신에 1 Mbps밖에 속도가 안나오게되서 저런 현상이 발생하는 것같습니다.
한마디로 wifi adhoc에서는 broadcast로 높은 쓰루풋을 취하는것은 불가능한것 같습니다.
확실한 스펙문서는 찾지 못했지만 제 추측입니다 ㅠ,ㅜ
non-promiscuous mode에서 packet을 받아 들일 때 destination mac을 보고 판별하는데 여기에는 3가지 조건이 있습니다.
1. dst mac이 자기 자신의 mac이냐?
2. dst mac이 broadcast mac(FF:FF:FF:FF:FF:FF)이냐?
3. dst mac이 multicast mac(01:00:5E:...)이냐?
그 외에도 몇가지 조건이 있습니다.
질문하신 부분은 2번으로 보이는데, 2번의 형식으로 자신이 보낸 packet을 자신이 recv하지 않도록 하는 방법은 OS 레벨을 뜯어 고치지 않는한 불가능합니다. 결국 이는 application 레벨에서 처리를 해 줘야 합니다. message header에 누가 보냈는지를 나타 내는 필드를 추가해서 이 정보를 가지고 판단(내가 보낸거냐 아니냐)을 하도록 해야 합니다.