Urain : 해당 서버는 지속적으로 키를 보내야 합니까? 이것은 트래픽을 증가시킬 것입니다. 글쎄, 하나님은 트래픽으로 그에게 축복을 주십니다. 메시지가 수신될 것이라는 보장은 어디에 있습니까? 이는 서버 측에서 각 메시지에 대한 변수 키 로그가 필요하다는 것을 의미하며, 프로거는 이 모든 부분에서 쉽게 혼동될 수 있습니다.
네, nifiga, 문제는 메시지 5-16-32-64에 핵심 기호를 추가하는 것입니다 ??? 메시지 크기 팽창은 어디에 있습니까? 이보다 여러 메시지에 대한 핸들을 더 많이 잃게 됩니다.
해당 서버는 지속적으로 키를 보내야 합니까? 이것은 트래픽을 증가시킬 것입니다. 글쎄, 하나님은 트래픽으로 그에게 축복을 주십니다. 메시지가 수신될 것이라는 보장은 어디에 있습니까? 이는 서버 측에서 각 메시지에 대한 변수 키 로그가 필요하다는 것을 의미하며, 프로거는 이 모든 부분에서 쉽게 혼동될 수 있습니다.
네, nifiga, 문제는 메시지 5-16-32-64에 핵심 기호를 추가하는 것입니다 ??? 메시지 크기 팽창은 어디에 있습니까? 이보다 여러 메시지에 대한 핸들을 더 많이 잃게 됩니다.
잠깐, 하지만 실제로 서버가 무언가를 보내야 하는 이유는 ftp에 쓰고 클라이언트가 거기에서 가져오도록 하는 것입니다.
별로. 컴퓨터는 서버에 대한 지속적인 요청으로 로드됩니다. 철 조각과 교통량을 적재하지 않는 것이 바람직할 것입니다.
아마도 모두 동일하지만 소켓 영구 연결을 만드는 것이 트래픽 측면에서 더 경제적입니까?
- 원격 동기화(데이터가 서버에 있음(어떤 형식으로))
- 클라이언트에게 줄 것(마지막 신호 또는 동기화를 위한 전체 주문 세트)
- 및 정보 교환 방법(신뢰성/자원 절약의 비율에서 승리하는 것은 클라이언트에 직접 연결되는 순수한 소켓 또는 서버의 지속적인 swotting이 있는 http/ftp)
별로. 컴퓨터는 서버에 대한 지속적인 요청으로 로드됩니다. 철 조각과 교통량을 적재하지 않는 것이 바람직할 것입니다.
아마도 모두 동일하지만 소켓 영구 연결을 만드는 것이 트래픽 측면에서 더 경제적입니까?
일반적으로 어떤 언어로 제한됩니까?
1) 고유 데이터베이스(근육)
2) HTTP 또는 HTTPS - 여기서 안정성과 안전성은 여전히 최우선입니다. 교통 - 90%의 사람들이 무제한에있을 때 논의하는 것은 의미가 없다고 생각합니다.
2) HTTP 또는 HTTPS - 여기서 안정성과 안전성은 여전히 최우선입니다. 교통 - 90%의 사람들이 무제한에있을 때 논의하는 것은 의미가 없다고 생각합니다.
지금까지 없음. 이상적인 안정적인 복사기에 대해 이야기
이상적인 안정적인 복사기는 서버당 수천 개의 클라이언트가 있는 MT 터미널이며 동시에 수백만 달러가 이 시스템에 위탁됩니다.
수년에 걸친 운영 개발, MT 서버를 구입한 수백 개의 회사.
MT 서버를 가져와 터미널에 모든 신호를 브로드캐스트하십시오.