Highly reliable transaction/signal copier (ideology discussion and development) - page 6
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
a simple exchange scheme: the signal generator places a file on the server with all its open orders and positions, as in the terminal. If at least one order or position has changed, it places a new file. In this case, the server sends a new version of the file (or a message with the full content of the file), and the client replies that he has received it (the server should contain the list of connected clients). The server also sends the file to the client at any time.
If the client is caught up or misses an order, it can easily restore itself by reading the server's terminal file. If there is a command-by-command exchange, there may be many crashes and ambiguities. Client can resynchronize for diagnostics e.g. once per Xmin if there was no change.
Traffic is not high with this scheme. So you can use SSL or https even.
There are 3 types of messages: give, receive, file itself.
a simple exchange scheme: the signal generator places a file on the server with all its open orders and positions, as in the terminal. If at least one order or position has changed, it places a new file. In this case, the server will send a new version of the file (or a message with the full content of this file). It also sends this file at any time on client's request.
If the client is caught up or misses an order, it can easily restore itself by reading the server's terminal file. If there is a command-by-command exchange, there may be many crashes and ambiguities. Client can resynchronize for diagnostics e.g. once per Xmin if there was no change.
Traffic is not high with this scheme. Therefore, you can use SSL or https even.
The scheme is useless, because the file with trading signal loses its relevance very quickly, because trades have to be executed in time. The fastest option is for the client to keep a constant connection to the server socket and wait for trading signals to appear. A permanent connection does not waste traffic unlike systematic requests and its reliability is quite high.
As I said before, no commands are needed either. As soon as a trading signal appears, the server sends it to the clients as a single line with the termination symbol "\n" and waits for the next one. The client does not have to send anything to the server, it only receives signals.
SSL and https is not needed at all. Firstly, the owner of the server will have to register a domain and buy a certificate and then he has to prolong all this stuff also not for free in order to work with these protocols. And secondly, these protocols are for data encryption, to intercept information in a TCP stream could not decrypt. The load on the server will be enormous if it has many clients, because encryption is not halam balam, but the operation of raising large integers to higher powers modulo.
The scheme is useless, because the trading signal file quickly loses its relevance, as trades need to be made on time. The fastest option is for the client to keep a constant connection to the server socket and wait for the trading signals to appear. A permanent connection does not waste traffic, unlike systematic requests, and its reliability is quite high.
As I said before, the client does not need any commands either. When a trade signal appears, the server sends it to the clients as a single line and waits for the next one. The client does not have to send anything to the server, only receive signals.
There is no delay, because it is sent to all clients immediately after the signal appears.
The command-by-command connection certainly saves traffic, but reliability will be poor. The client should be able to obtain all of the orders (for example, pending orders or order modifications) even that he missed for some reason.
There is no delay because the message is sent immediately to all clients after the signal appears.
Team-by-team, of course, saves traffic, but the reliability will be poor. The client should be able to retrieve all orders (pending orders for example, or order modifications), even those missed for some reason.
Ok, make a humpback. Only who will do such nonsense - it is not my problem.
My job is to offer the best option with the minimum load and traffic, you have the right to refuse.
SSL and https are not needed at all. In the first place, the server owner must register a domain and buy a certificate, and then permanently renew it is also not for free, to work with such protocols. And secondly, these protocols for data encryption, to intercept information in a TCP stream could not decrypt it. The load on the server will be enormous if it has many clients, because encryption is not halam balam, but the operation of raising large integers to higher powers modulo.
But all existing unauthenticated server-signals are cracked in a couple of hours. Although encryption may be unnecessary))
but all existing server-signals without authentication can be cracked in a couple of hours. Encryption may be unnecessary though)).
1. Not hours, but milliseconds
2) Who the hell needs your signals to be opened by someone else? Anecdote about Elusive Joe.
All right, make a humpback of it. But who will do such nonsense is no longer my problem.
My job is to offer the best option with minimum load and traffic, you have the right to refuse.
1. Not hours, milliseconds.
2) Who the fuck needs your signals to be covered up? Anecdote about Elusive Joe.
I don't give a shit, but people who sell signals for money get upset)) But if it is not important in this project - no problem, no need for protection
If client has lost connection, or rebooted, and in the meantime some pending orders or modifications of orders passed, how to fix it with telnet command exchange? I don't know, maybe you can - that's why I'm asking.
I've already told you that you don't need a command telnet, but you're talking nonsense again.
You should duplicate files and upload them to some cheap hosting using SendFTP(). And let the client read the files by FTP with the time of creation when he was out of contact.
I've already told you that you don't need a command telnet, but you're talking nonsense again.
You should duplicate the files and upload them to some cheap hosting using SendFTP(). And let the client read the files via FTP with the creation time it was out of connect.
I.e. it's not yours))
Reshetov:
Socket over TCP/IP protocol. You can transmit signals in text form in one line per signal, such as "EURUSD Buy 1.0\n", as via Telnet, because it is the most primitive version that does not require a complex exchange procedure, as in http or ftp protocols with minimum parsing.
You're talking nonsense again - duplicate one with the other when you can do with one)). Why bother storing files, when one is enough - the last one with the current state of all orders and positions? To combine the exchange on demand of the server (when something has changed on the master account) and on demand of the client (when he had problems or inconsistencies), and not to come up with additional crutches. You can send not the whole order file on server's request, but only what has changed and it will be your version of "command exchange".