[Q] 네트워크 프로그래밍할 때 데이터가 뭉쳐서(?) 들어와요...
글쓴이: downer2k / 작성시간: 월, 2004/11/15 - 9:41오전
클라이언트는 윈도이고 서버를 리눅스로 하였습니다.
클라이언트에서 사인파를 만들어서 서버로 보냈는데, 로칼 네트워크에서는
아주 부드럽게 커브가 들어오는데... (어찌보면 당연하겠죠..?) 근데
원거리(미국 --> 한국)에서 할 때는 신호가 뭉쳐서 들어옵니다.
즉 플로팅을 하면 마치 사인파 안에 계단들이... -.-;;
(계단에서 수평부분에는 신호가 안들어오고 수직 부분에 신호가 뭉쳐들어온거죠.., 전송시간지연이 불규칙하다고 한다 해도 그 계단이 거의 일정간격이던데 그 문제는 아닌거 같습니다.)
예전에 윈도 --> 윈도 일 때는 이런 문제가 별로 없었는데.. 혹시 운영체제가 달
라서 생기는 현상일까요??
File attachments:
첨부 | 파일 크기 |
---|---|
figure.JPG | 28.93 KB |
Forums:
저두 클라이언트는 윈도우, 서버는 리눅스로 작업을하고 있는데...
저두 클라이언트는 윈도우, 서버는 리눅스로 작업을
하고 있는데...죄송한데요..혹시 리눅스 소스를
볼수 있을까요?...
wyw0093@hotmail.com 입니다.
뭉쳐서 들어오면 원래 받기 원하셨던 크기로 잘 잘라서 보여주시면 될듯 한
뭉쳐서 들어오면 원래 받기 원하셨던 크기로 잘 잘라서 보여주시면 될듯 한데요.
아무래도 서버측에서는
AAA 한번 BBB 한번 보냈는데
클라이언트에서는
AAABBB 한번으로 온다는 말씀같습니다.
그런데 현재 클라이언트에서는 자르는 것 없이 그냥 처리해서 앞의 데이터만 처리해서 결과적으로 뒤에 붙은 데이터가 유실되어서 그림의 계단(?)처럼 보이는 듯 합니다.
그러면 그냥
AAABBB를 AAA, BBB로 잘라서 클라이언트에서 처리해 주시면 될듯합니다.
네트웍으로 날아오는 데이타는 스트림 형태입니다..위엣분이 말씀하신
네트웍으로 날아오는 데이타는 스트림 형태입니다..
위엣분이 말씀하신 것처럼 aaa 를 보내고 좀있다가 bbb 를 보내도
받을때에는 한큐에 aaabbb 로 받을수도 있다는거죠.
반대로 aa 를 받고 abbb 를 한참있다가 받을수도 있습니다.
이걸 해결하기 위해서는 각각의 패킷을 쪼갤수 있는 방법(프로토콜) 이 필요해집니다.
즉 3aaa3bbb2cc 와 같이 보내면 aaa bbb cc 로 쪼개서 처리하는것이 가능해 집니다.
처음 질문한 사람인데요.. 데이터를 보낼때 구조체로 먼저 만들어서
처음 질문한 사람인데요..
데이터를 보낼때 구조체로 먼저 만들어서 보냈습니다.
서버측 소스는 다음과 같습니다.
10msec간격으로 클라이언트에서 송신했습니다.
text파일에 저장한 결과를 아래에 넣었으며(너무 길어서 처음 일부만.. ^^)
각 column은 다음과 같습니다.
1. 클라이언트에서 보낸 인덱스
2. 서버에서 각 신호를 read했을 때 시간
3. 사인파 신호
보시면 아시다시피 인덱스 1~19까지 거의 동시에 들어오고 잠시 쉬었다가 20부터 36까지 거의 동시에 들어오고 있습니다.
앞에분들 말씀대로 TCP는 스트림형태라 데이터가 뭉쳐(?)들어올수도 있습
앞에분들 말씀대로 TCP는 스트림형태라 데이터가 뭉쳐(?)들어올수도 있습니다.
서버에서 Send하실때 리턴값(전송한 바이트수)과 클라이언트에서 Read하실때 리턴값(수신한 바이트수)를 확인해보세요.
서버에서 맞게 전송된다면 클라이언트에서 수신 Queue를 두어 구조체 크기만큼 잘라서 사용하시면 될듯하네요.
제가 잘 몰라서 그러는데요... [quote]앞에분들 말씀대로 T
제가 잘 몰라서 그러는데요...
라고 하셨는데.. 수신 Queue는 어떻게 만드는 것인가요..?
그리고 위의 소스에서 올린것처럼 recvn이라는 함수를 만들어서 정해진 (구조체의) 크기만큼 받도록 루프를 돌면서 계속 recv를 호출하도록 하였는데, 이걸로는 부족한 것이 있는 것인가요..?
세상의 중심에서 사랑을 외치다
혹시 byte ordering이나 구조체의 packed에 대한 문제는 아
혹시 byte ordering이나 구조체의 packed에 대한 문제는 아닐까요?
실제 네트웍 프로그램을 많이 햅진 않았는데.
저 같은 경우는 byte ordering이나 구조체의 packed 문제가 가장 많더군요.
...
...
.
음. 제가 대략..쓰레드들을 훝어봐서 잘못 알고 답변드리는것일수도 있습니다만,
사인파 곡선그리실때 가로축이 시간 세로축이 전송받으신 데이터신가요?
그 가로축 시간값은 서버에서 데이터를 받은 시각을 사용하시나요? (적어주신 텍스트 데이터값)
만약, 그렇다면 그것은 데이터를 어떻게 보내고, 어떻게 받고의 문제가 아니라..
일단, 미국에서 온다면 중간에 수없이 거치는 TCP/IP Layer들을 거치면서 최대로 효율을 올리기 위해 MTU 단위로 뭉쳐지는 과정들을 거치면서 지금처럼 거의 같은시간에 여러 패킷이 한꺼번에 도달하게 될 확률이 매우 높을것입니다.
위의 제 질문이 맞는 내용이라면 패킷내용에 시간도 포함해서 (클라이언트에서 각 사인데이터를 발생시킬때의 시각) 보내주고, 서버에서는 한꺼번에 받던,,한개씩 받던..상관없이 구조체 단위로 패킷을 쪼개서 x,y값을 사용해서 그래프를 그리시면 될것 같습니다.
만약, 미국의 클라이언트가 이미 y축 데이터만 보낼수 밖에 없도록 고정화되어 있다면, 전체 시간을 패킷갯수(구조체 갯수의미) 로 나누어 나오는 평균시간을 각 x축 시간으로 써도 될 것 같습니다.
댓글 달기