왜 그런 정글에 올라? TCP/IP 작업을 위한 표준 컨트롤이 있으며 이 비즈니스를 위한 별도의 프로그램을 작성하십시오. 어드바이저 터미널에서 프로그램과 어드바이저의 연결(한 대의 컴퓨터 내에서 어떤 식으로든 편리함) ... 그리고 바퀴를 재발명할 필요가 없습니다. 포트를 들어보세요. 장기.
왜 그런 정글에 올라? TCP/IP 작업을 위한 표준 컨트롤이 있으며 이 비즈니스를 위한 별도의 프로그램을 작성하십시오. 어드바이저 터미널에서 프로그램과 어드바이저의 연결(한 대의 컴퓨터 내에서 어떤 식으로든 편리함) ... 그리고 바퀴를 재발명할 필요가 없습니다. 포트를 들어보세요. 장기.
드미트리, 반복합니다. 복사기는 오랫동안 약 4-5년 된 광고였습니다. 로컬 및 원격, 그리고 중간 서버와 함께. 내 말을 듣는 컨트롤은 필요하지 않습니다.
여기에서 나는 이것에 대해 개를 먹은 사람들 사이에서 일반적인 포럼 토론을 하고 싶습니다. 그리고 파생된 기술의 장단점 을 기반으로 - 클라이언트 수는 물론 연결 품질 및 채널의 부하 모두에 대해 안정적이고 내성이 있는 안정적인 복사기에 대한 옵션을 만듭니다.
그리고 파생된 기술의 장단점 을 기반으로 - 클라이언트 수는 물론 연결 품질 및 채널의 부하 모두에 대해 안정적이고 내성이 있는 안정적인 복사기에 대한 옵션을 만듭니다.
의제에 있는 것은 두 가지 위험입니다.
1 통신 문제로 인해 신호를 받지 못했습니다.
2 전송 시 비트 손실로 인해 올바른 메시지를 수신하지 못합니다.
그러면 서로 다른 소스에서 3개의 신호를 수신한 인접 클라이언트 간의 통신 없이는 할 수 없습니다. 비트 단위 확인을 수행하고 "3 중 2" 원칙에 따라 실제 메시지를 표시할 수 있습니다. 이러한 체계는 통신 실패와 전송 손실 모두로부터 더 보호됩니다. 그런 다음 메시지를 비트 마스크로 암호화하고 최소로 압축할 수 있습니다(문장 문자열을 전송하는 대신). 그러면 서버 트래픽이 줄어듭니다.
위협 그리고 넘어진 이웃으로 인한 실패가 없도록 과도하게 분포를 형성한다. 예를 들어 클라이언트는 서버와 이웃 4개로부터 신호를 받지만 서버 신호는 먼저 온 이웃들로부터 2개 신호를 받는다. 운영에 들어갑니다.
클라이언트와의 의사 소통 부족은 어떤 식 으로든 해결되지 않습니다. 그녀는 존재하거나 존재하지 않습니다. 서버는 항상 연결되어 있다고 가정합니다.
2 전송 시 비트 손실로 인해 올바른 메시지를 수신하지 못합니다.
예를 들어 해시를 사용하여 잘못된 메시지에 서명할 수 있습니다. 값이 올바르지 않으면 서버에서 메시지를 다시 요청합니다. 그러나 일반적으로 @label@과 같은 특수 태그가 있는 파일의 끝과 중간에 존재하는 것은 이미 수신된 메시지의 완전성에 대해 모호하지 않은 영역을 만듭니다.
...다른 소스에서 세 개의 신호를 수신한 인접 클라이언트 간의 통신 없이는 할 수 없습니다. . 이러한 체계는 통신 실패와 전송 손실 모두로부터 더 보호됩니다. 그런 다음 메시지를 비트 마스크로 암호화하고 최소로 압축할 수 있습니다(문장 문자열을 전송하는 대신). 그러면 서버 트래픽이 줄어듭니다.
왜 그런 정글에 올라? TCP/IP 작업을 위한 표준 컨트롤이 있으며 이 비즈니스를 위한 별도의 프로그램을 작성하십시오. 어드바이저 터미널에서 프로그램과 어드바이저의 연결(한 대의 컴퓨터 내에서 어떤 식으로든 편리함) ... 그리고 바퀴를 재발명할 필요가 없습니다. 포트를 들어보세요. 장기.
그게 요점입니다. 내가 생각하려고 하는 것. 물론 처음에는 더 많은 확장성을 투자해야 합니다. 즉, 목표는 1000-h에 대해 수행하는 것입니다. 그리고 나중에 유닛이 사용하는 것은 중요하지 않습니다.
이것이 내가 지금 선택하고 결정하려고 하는 이유입니다. 소켓이 있는 속도와 마이크로 트래픽 중 하나입니다. 또는 정보의 새로운 부분에 대한 클라이언트의 지속적인 swotting에 http 및 상당한 트래픽 .
두 번째 옵션이 더 낫다고 생각합니다. 확장성이 필요하고 그 중 소수에 불과한 사람들은 어떤 경우에도 추가 비용을 부담해야 합니다. 해당 트래픽에 대한 비용을 지불하게 하십시오.
나머지는 90%의 경우 소수의 클라이언트와 함께 사용되며 연결의 안정성, 따라서 이 경우 기능이 트래픽보다 더 중요합니다.
그리고 첫 번째 경우에는 안정적인 연결이 없으면 좋은 솔루션이 작동하지 않습니다.
그게 요점입니다. 내가 생각하려고 하는 것. 물론 처음에는 더 많은 확장성을 투자해야 합니다. 즉, 목표는 1000시간 동안 하는 것입니다. 그리고 나중에 유닛이 사용하는 것은 중요하지 않습니다.
이것이 내가 지금 선택하고 결정하려고 하는 이유입니다. 소켓이 있는 속도와 마이크로 트래픽 중 하나입니다. 또는 새로운 정보 부분에 대한 클라이언트의 끊임없는 swotting에 대한 http 및 상당한 트래픽.
그리고 정보를 받은 클라이언트 자체가 서버가 되어 특정 클라이언트 집합에 배포하면 어떻게 될까요? 스카이프처럼.
그런 다음 확장 가능한 네트워크가 있습니다. 규모는 작지만 주문은 서버에서 직접 전달되며 네트워크가 커지자 마자 두 번째 계층, 세 번째 계층이 나타납니다. 이 경우 서버의 부하가 증가하지 않습니다. 네트워크는 시스템 간에 ping을 통해 구성됩니다.
그리고 정보를 받은 클라이언트 자체가 서버가 되어 특정 클라이언트 집합에 배포하면 어떻게 될까요? 스카이프처럼.
방금 뉴스 시청) https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA
P2P를 사용하면 유사점이 없는 "혁명적인" 솔루션이 될 것입니다)
그것이 진짜인지, 일반적으로 이것에 편의가 있는지 생각하면됩니다.
방금 뉴스 시청) https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA
P2P를 사용하면 유사점이 없는 "혁명적인" 솔루션이 될 것입니다)
그것이 진짜인지, 일반적으로 이것에 편의가 있는지 생각하면됩니다 .
그리고 정보를 받은 클라이언트 자체가 서버가 되어 특정 클라이언트 집합에 배포하면 어떻게 될까요? 스카이프처럼.
옵션은 좋은데 규모가 크네요 :) 클라이언트와 마스터를 동기화 하기 위해서는 클라이언트끼리 추가 교환을 하는건 무리라고 생각합니다.
물론 각 클라이언트는 수신된 정보를 보내기 위한 미니 서버가 되지만 이는 원칙적으로 고려할 가치가 있습니다.
왜 그런 정글에 올라? TCP/IP 작업을 위한 표준 컨트롤이 있으며 이 비즈니스를 위한 별도의 프로그램을 작성하십시오. 어드바이저 터미널에서 프로그램과 어드바이저의 연결(한 대의 컴퓨터 내에서 어떤 식으로든 편리함) ... 그리고 바퀴를 재발명할 필요가 없습니다. 포트를 들어보세요. 장기.
여기에서 나는 이것에 대해 개를 먹은 사람들 사이에서 일반적인 포럼 토론을 하고 싶습니다. 그리고 파생된 기술의 장단점 을 기반으로 - 클라이언트 수는 물론 연결 품질 및 채널의 부하 모두에 대해 안정적이고 내성이 있는 안정적인 복사기에 대한 옵션을 만듭니다.
..
그리고 파생된 기술의 장단점 을 기반으로 - 클라이언트 수는 물론 연결 품질 및 채널의 부하 모두에 대해 안정적이고 내성이 있는 안정적인 복사기에 대한 옵션을 만듭니다.
의제에 있는 것은 두 가지 위험입니다.
1 통신 문제로 인해 신호를 받지 못했습니다.
2 전송 시 비트 손실로 인해 올바른 메시지를 수신하지 못합니다.
그러면 서로 다른 소스에서 3개의 신호를 수신한 인접 클라이언트 간의 통신 없이는 할 수 없습니다. 비트 단위 확인을 수행하고 "3 중 2" 원칙에 따라 실제 메시지를 표시할 수 있습니다. 이러한 체계는 통신 실패와 전송 손실 모두로부터 더 보호됩니다. 그런 다음 메시지를 비트 마스크로 암호화하고 최소로 압축할 수 있습니다(문장 문자열을 전송하는 대신). 그러면 서버 트래픽이 줄어듭니다.
위협 그리고 넘어진 이웃으로 인한 실패가 없도록 과도하게 분포를 형성한다. 예를 들어 클라이언트는 서버와 이웃 4개로부터 신호를 받지만 서버 신호는 먼저 온 이웃들로부터 2개 신호를 받는다. 운영에 들어갑니다.
의제에 있는 것은 두 가지 위험입니다.
1 통신 문제로 인해 신호를 받지 못했습니다.
클라이언트와의 의사 소통 부족은 어떤 식 으로든 해결되지 않습니다. 그녀는 존재하거나 존재하지 않습니다. 서버는 항상 연결되어 있다고 가정합니다.
2 전송 시 비트 손실로 인해 올바른 메시지를 수신하지 못합니다.
예를 들어 해시를 사용하여 잘못된 메시지에 서명할 수 있습니다. 값이 올바르지 않으면 서버에서 메시지를 다시 요청합니다. 그러나 일반적으로 @label@과 같은 특수 태그가 있는 파일의 끝과 중간에 존재하는 것은 이미 수신된 메시지의 완전성에 대해 모호하지 않은 영역을 만듭니다.
...다른 소스에서 세 개의 신호를 수신한 인접 클라이언트 간의 통신 없이는 할 수 없습니다. . 이러한 체계는 통신 실패와 전송 손실 모두로부터 더 보호됩니다. 그런 다음 메시지를 비트 마스크로 암호화하고 최소로 압축할 수 있습니다(문장 문자열을 전송하는 대신). 그러면 서버 트래픽이 줄어듭니다.