Highly reliable transaction/signal copier (ideology discussion and development) - page 7
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
OK. Then I propose to take socket connection as a working model.
Схема работы синхронизатора:
- The server will create permanent socket connections with clients (the issue of assigning each client its own thread is still under consideration).
- the master-client sends the current state of his orders during a trade event
- the server saves this file and sends it to all other clients immediately (a socket connection is already established)
- the client receives the file and changes the order state according to the received data
- The last saved file of the wizard is also sent to the client when a new client connects. (for initial synchronization)
The main advantage of this system is the traffic savings:
- It does not require constant requests from the client. It will receive them from the server on their availability
- Similarly, the master-client will send data only when changes are detected
Protection in case of connection loss
- the client sends a "Heartbeat" packet (e.g. 2 bytes) every 5 seconds to check communication with the server
- The client reinitializes the connection if the packet is sent unsuccessfully (no answer).
- server does the same. If no response is received from the client within 10 seconds, the socket connection is closed.
Is there a disadvantage of this connection?
- e.g. what is the maximum possible number of socket connections available?
Protection in case of loss of connection
- The client sends a "Heartbeat" packet (e.g. 2 bytes) every 5 seconds to check communication with the server
This is never done when communicating via the TCP/IP transport protocol because communication is maintained automatically at the socket layer, i.e. by the operating system. In case of broken connections, an exception is thrown on the client and its handler has to specify what exactly needs to be done in such a case. As far as server is concerned, it doesn't give a shit, because if client is disconnected, it's already client's problem.
- e.g. what is the maximum possible number of socket connections available?
If connections are broken and an exception is raised on the client, an exception must be raised in its handler
Which exception are you talking about?
I'm talking about the WS2_32.dll. Usual Berkeley sockets (though in asynchronous variant). Didn't see any exceptions there. You can only detect a crash by trying to send/receive.
how many socket connections can be made on this port ?
Which exception are you talking about?
Well, you only need one port.I'm talking about the WS2_32.dll. Ordinary Berkeley sockets (though in asynchronous version). Didn't see any exceptions there. You can only detect a crash by trying to send/receive.
I'm interested in how many socket connections can be attached to this port ?
There is only one connection per port. In order for the client to connect it must know what IP and port number is allocated on the server. Alternatively, you can specify a domain name instead of IP and the socket will resolve it to an IP address via DNS.
Server socket listens to this very port number to connect from clients. When the client connects, the socket will give it another port from the pool of free ports to keep it connected. The persistent port is then released again and listens for connections from other clients.
This is how TCP/IP transport protocol connections are made. All this is done at the socket layer, i.e. you don't need to program the protocol - it's standard and it's already hardwired into the shared library in the operating system.
When a client connects, the socket will allocate another port from the pool of free ports to keep it permanently connected.
Yuri, thank you for the basics, but it's out of place. You're giving the wrong knowledge.
And the allocated one is nonsense at all, sorry. Maybe you are applying port concepts in two different hypostases, but then you better work in accepted concepts.
something might come in handy for development
unlikely. unprofessional.
And the highlighted one is nonsense, sorry. Maybe you are applying port concepts in two different guises, but then you'd better work in accepted concepts.
As they say, it's your own problem how you apply the concept of port. I only explained how ports are used in the TCP/IP protocol. Once again, the protocol is standard, i.e. I did not invent it.
I'm not the one who invented it.
Good luck!
What is the order of network size, how many clients are supposed to be 1000-thousand, 100-thousand, 10-thousand, 1-thousand?
Because your server will really go bankrupt with thousands of clients.
What is the order of network size, how many clients are supposed to be 1000-thousand, 100-thousand, 10-thousand, 1-thousand?
Because your server will really go bankrupt with thousands of clients.
That's the point. I'm trying to think comprehensively. Of course, you have to put in a lot of scalability initially. That is, the goal is to do as much as for 1,000h. And it doesn't matter that only a few people will use it later.
That's why now I'm trying to choose and make up my mind - either speed and micro-traffic with sockets. Or http and a lot of traffic on constant chasing of clients for a new portion of information.