1. 거래가 이루어지면 TRADE_TRANSACTION_DEAL_ADD --> ORDER_STATE_STARTED 메시지를 받아야 합니까?
2. TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_REQUEST_MODIFY 주문 수정 중이라는 메시지 후
TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_PLACED 메시지를 받아야 합니까?
질문은 아니지만 대답하려고 노력할 것입니다 :)
이벤트 작업은 예상되는 이벤트가 발생하지 않을 수 있음을 의미합니다. 예를 들어 도중에 길을 잃거나 줄을 서서 기다리지 않을 수 있지만 거의 발생할 수 없습니다(터미널 버그 포함). 따라서 안정적인 운영을 위해서는 이벤트 모델을 보호해야 합니다. 예를 들어 특별히 중요한 이벤트에 대한 대기자 명단을 작성하고 관련 이벤트뿐만 아니라 예상 이벤트가 발생했음을 간접적으로 확인하여 관리합니다.
그리고 두 번째로, 5000유로의 보증금으로 귀하의 비용으로 테스트하는 경우 선불은 무엇입니까?
나는 항상 내 전제 조건을 드러낸다. 내 전제 조건에 동의한 후 TOR를 읽고 다음과 같이 말합니다. 합의 후 TOR에 대해 세세한 부분까지 논의합니다. 그리고 완전한 상호 이해 후에만 일할 준비가 되었음을 확인합니다. 작업하는 동안 우리는 고객과 긴밀하게 협력합니다. 항상 연락합니다. 우리는 알고리즘의 각 "톱니바퀴"에 대한 토론과 설명을 계속합니다. 다음 "톱니"가 연마되고 테스트될 때까지 다음으로 진행하지 않습니다. 완성된 솔루션을 전송하기 전에 알고리즘에 오류가 있는지 직접 테스트하지만 테스터에서만 알고리즘의 정확성에 대해서만 테스트합니다. 계정에 대한 테스트 - 고객이 비용을 부담하고 버그를 찾는 데만 사용됩니다.
이벤트 작업은 예상되는 이벤트가 발생하지 않을 수 있음을 의미합니다. 예를 들어 도중에 길을 잃거나 대기열에서 기다리지 않지만 거의 발생할 수 없습니다(터미널 버그 포함). 따라서 안정적인 운영을 위해서는 이벤트 모델을 보호해야 합니다. 예를 들어 특별히 중요한 이벤트에 대한 대기자 명단을 작성하고 관련 이벤트뿐만 아니라 예상 이벤트가 발생했음을 간접적으로 확인하여 관리합니다.
아니요, 굴러가지 않습니다. 이벤트 모델 은 절대적으로 신뢰할 수 있어야 합니다. 이벤트가 도달하지 않으면 존재하지 않습니다. FORTS에서 이벤트는 특히 명확하게 실행되어야 합니다. 주문을 변경하면 수십 개의 거래가 발생할 수 있습니다.
미칼라스 :
그리고 감사합니다. 하지만 저는 그렇게 할 것이라고 생각합니다.
Plaza II로 "크롤링"합니다.
나는 조언하지 않습니다. 이 버그를 MQ와 함께 수정하는 것이 광장 아래에 새 터미널을 단독으로 차단하는 것보다 훨씬 쉽습니다. 끝없는 수정 결함과 "표준 기능" 작성에 얽매이십시오. 나는 내 자신의 경험에서 말합니다. 특정 작업에 대한 또 다른 "자전거"의 결과인 Stock #을 기반으로 자체 제작한 복합 단지 중 하나를 부분적으로 개발했습니다. 지원 서비스와 싸우는 것이 더 좋고 더 쉽고 저렴할 것입니다.
그럼에도 불구하고 이러한 한 번, 두 번 또는 세 번은 가장 부적절한 순간에 발생할 수 있습니다. 바로 여러분에게 일어난 일입니다. 그런데 도움말에서 이에 대해 자세히 설명합니다. 그리고 개발자 자신 은 다른 거래가 도착한 후 일부 거래가 수신될 것으로 예상하여 거래 알고리즘을 구축하는 것을 권장하지 않습니다.
터미널에서 또는 OrderSend() / OrderSendAsync() 거래 기능을 통해 수동으로 전송된 하나의 거래 요청은 거래 서버에서 여러 개의 연속 거래 거래를 생성할 수 있습니다. 동시에 터미널에서 이러한 거래를 수신하는 순서는 보장되지 않으므로 다른 거래가 도착한 후 일부 거래가 수신될 것으로 예상하여 거래 알고리즘을 구축할 수 없습니다. 또한 서버에서 단말로 전달하는 과정에서 거래가 손실될 수 있습니다.
2가지 간단한 질문에 답하십시오.
1. 거래가 이루어지면 TRADE_TRANSACTION_DEAL_ADD --> ORDER_STATE_STARTED 메시지를 받아야 합니까?
2. TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_REQUEST_MODIFY 주문 수정 중이라는 메시지 후
TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_PLACED 메시지를 받아야 합니까?
질문은 아니지만 대답하려고 노력할 것입니다 :)
이벤트 작업은 예상되는 이벤트가 발생하지 않을 수 있음을 의미합니다. 예를 들어 도중에 길을 잃거나 줄을 서서 기다리지 않을 수 있지만 거의 발생할 수 없습니다(터미널 버그 포함). 따라서 안정적인 운영을 위해서는 이벤트 모델을 보호해야 합니다. 예를 들어 특별히 중요한 이벤트에 대한 대기자 명단을 작성하고 관련 이벤트뿐만 아니라 예상 이벤트가 발생했음을 간접적으로 확인하여 관리합니다.
Artyom, 나는 당신의 말을 듣고 싶지 않지만 당신 편에서는 그렇지 않습니다
고려 단계. 사실은 현재 오류가
내 TOR에 따르면 고문을 작성할 수 있습니다.
지금 제 고문은 일을 하며 하루에 1%의 수익을 올리고 있습니다.
철저하게 현대화하고 싶었지만 오류로 인해
MT-5는 실패합니다.
그리고 두 번째로, 5000유로의 보증금으로 귀하의 비용으로 테스트하는 경우 선불은 무엇입니까?
나는 항상 내 전제 조건을 드러낸다. 내 전제 조건에 동의한 후 TOR를 읽고 다음과 같이 말합니다. 합의 후 TOR에 대해 세세한 부분까지 논의합니다. 그리고 완전한 상호 이해 후에만 일할 준비가 되었음을 확인합니다. 작업하는 동안 우리는 고객과 긴밀하게 협력합니다. 항상 연락합니다. 우리는 알고리즘의 각 "톱니바퀴"에 대한 토론과 설명을 계속합니다. 다음 "톱니"가 연마되고 테스트될 때까지 다음으로 진행하지 않습니다. 완성된 솔루션을 전송하기 전에 알고리즘에 오류가 있는지 직접 테스트하지만 테스터에서만 알고리즘의 정확성에 대해서만 테스트합니다. 계정에 대한 테스트 - 고객이 비용을 부담하고 버그를 찾는 데만 사용됩니다.
나는 이것이 아무것도 아닌 대화라는 것을 이해합니다. 그만하자
P/S 어떤 고급 언어를 구사합니까?
우리는 이미 "보지로 자신을 측정"하기 시작 했습니까?
나는 대답한다 - 욕
좋은 오후, 유리!
예, 물론 맞습니다. 이벤트는 한 번, 두 번 또는 세 번 오지 않을 수 있습니다.
그러나 그들은 왔지만 OTHER!
주문이 수정되었는지(서버 응답 없이) 제어하는 방법을 알려주시겠습니까?
우리는 이미 "보지로 자신을 측정"하기 시작 했습니까?
나는 대답한다 - 욕
Artyom, 당신은 어떻게 든 질문을 왜곡되게 이해하고 있습니다!
나는 당신에게 제안할 수 있다고 생각했습니다. (고문 대신에)
Plaza II의 작은 터미널, 하나는 어려울 것입니다 ...
Artyom, 당신은 어떻게 든 질문을 왜곡되게 이해하고 있습니다!
나는 당신에게 제안할 수 있다고 생각했습니다. (고문 대신에)
Plaza II의 작은 터미널, 하나는 어려울 것입니다 ...
죄송합니다. 당신을 오해했습니다. 그래도 피로는 영향을 미칩니다-복잡한 주문으로 일하고 잠이 거의 없습니다 ....
제안해 주셔서 감사합니다. 내 계획은 조금 다릅니다. 나는 아마 거절할 것이다.
질문은 아니지만 대답하려고 노력할 것입니다 :)
이벤트 작업은 예상되는 이벤트가 발생하지 않을 수 있음을 의미합니다. 예를 들어 도중에 길을 잃거나 대기열에서 기다리지 않지만 거의 발생할 수 없습니다(터미널 버그 포함). 따라서 안정적인 운영을 위해서는 이벤트 모델을 보호해야 합니다. 예를 들어 특별히 중요한 이벤트에 대한 대기자 명단을 작성하고 관련 이벤트뿐만 아니라 예상 이벤트가 발생했음을 간접적으로 확인하여 관리합니다.
아니요, 굴러가지 않습니다. 이벤트 모델 은 절대적으로 신뢰할 수 있어야 합니다. 이벤트가 도달하지 않으면 존재하지 않습니다. FORTS에서 이벤트는 특히 명확하게 실행되어야 합니다. 주문을 변경하면 수십 개의 거래가 발생할 수 있습니다.
그리고 감사합니다. 하지만 저는 그렇게 할 것이라고 생각합니다.
Plaza II로 "크롤링"합니다.
나는 조언하지 않습니다. 이 버그를 MQ와 함께 수정하는 것이 광장 아래에 새 터미널을 단독으로 차단하는 것보다 훨씬 쉽습니다. 끝없는 수정 결함과 "표준 기능" 작성에 얽매이십시오. 나는 내 자신의 경험에서 말합니다. 특정 작업에 대한 또 다른 "자전거"의 결과인 Stock #을 기반으로 자체 제작한 복합 단지 중 하나를 부분적으로 개발했습니다. 지원 서비스와 싸우는 것이 더 좋고 더 쉽고 저렴할 것입니다.
좋은 오후, 유리!
예, 물론 맞습니다. 이벤트는 한 번, 두 번 또는 세 번 오지 않을 수 있습니다.
그러나 그들은 왔지만 OTHER!
그럼에도 불구하고 이러한 한 번, 두 번 또는 세 번은 가장 부적절한 순간에 발생할 수 있습니다. 바로 여러분에게 일어난 일입니다. 그런데 도움말에서 이에 대해 자세히 설명합니다. 그리고 개발자 자신 은 다른 거래가 도착한 후 일부 거래가 수신될 것으로 예상하여 거래 알고리즘을 구축하는 것을 권장하지 않습니다.
터미널에서 또는 OrderSend() / OrderSendAsync() 거래 기능을 통해 수동으로 전송된 하나의 거래 요청은 거래 서버에서 여러 개의 연속 거래 거래를 생성할 수 있습니다. 동시에 터미널에서 이러한 거래를 수신하는 순서는 보장되지 않으므로 다른 거래가 도착한 후 일부 거래가 수신될 것으로 예상하여 거래 알고리즘을 구축할 수 없습니다. 또한 서버에서 단말로 전달하는 과정에서 거래가 손실될 수 있습니다.
//---
주문이 수정되었는지(서버 응답 없이) 제어하는 방법을 알려주시겠습니까?
예를 들어, 이전 값을 현재 값과 비교합니다.
아니요, 굴러가지 않습니다. 이벤트 모델은 절대적으로 신뢰할 수 있어야 합니다. 이벤트가 도달하지 않으면 존재하지 않습니다. FORTS에서 이벤트는 특히 명확하게 실행되어야 합니다. 주문을 변경하면 수십 개의 거래가 발생할 수 있습니다.
이벤트 모델 은 정의에 따라 절대적으로 신뢰할 수 없습니다. 이벤트가 도달하지 않았다고 해서 이벤트가 존재하지 않았다는 의미는 아닙니다.
톨64!
예, 도착하는 방법은 중요하지 않습니다("주문 접수" 이벤트가 먼저 발생하고 "수정 상태의 주문"이 뒤따른다는 것은 논리적이지 않음).
안 그래?
제 사진을 잘 보시면 "주문 완료"가 아니라 "부분적으로 채워진 주문"(두 개 연속으로 있음) 메시지가 도착한 것을 보실 수 있습니다!
P / S 그리고 다음과 같이 시작하는 전체 문장과 "텍스트를 빼낼" 필요가 없습니다.
거래 유형을 알면 거래 계정 의 주문, 포지션 및 거래의 현재 상태 에 대한 분석을 결정할 수 있습니다.