Highly reliable transaction/signal copier (ideology discussion and development) - page 2

New comment
 
Integer:
Everything has already been thought of, but I'm sorry, it's not unpleasant.

Dima, I know, of course, I also have everything invented and done, both locally and remotely in different guises.

But I just want to discuss this rather hackneyed topic, which, in my opinion, has not been raised here at all in this context.


If you have something to say on the subject, then speak up.

 

The client copies its parameters and creates an order with a magik equal to the original ticket. in this way we bypass the double setting.

After that the client should check the state of the order and report the execution (if there is something to execute), or its vivacity if the request is a control.

 
sergeev:

In the beginning, it all comes down to the mailing system itself. One server, many clients. If the system works, you can load the rest on this skeleton.

When the client connects, he sends a connection request, the server returns a signature in a special message, by which he will control the responses. Signature is not valid until client does not return it with special message. When everything is in order it is possible to start communicating.

So it has signatures of each client issued by the server (thus unrepeated). Server sends out messages with counter numbers (also should store message log at some depth in case some of the clients needs to repeat it), clients receive numbered message and send signed copy to server. This way server knows which client lost the message and can resend it. After x repetition the server stops sending this message, closes the session with this client, and starts waiting for the client to request a new session.

 
Why go to all that trouble, the variable key can be put in the message itself.
 
FAQ:

The client copies its parameters and creates an order with a magik equal to the original ticket. in this way we bypass the double setting.

ok. classic scheme.

After that the client should check the state of the order and report its fulfillment (if there is something to fulfill), or its vivacity if the request is a control.

And what's the point of doing this? The server still can't affect the client in any way.
 
FAQ:
Why such complications, the variable key can be put in the message itself.
So the server has to send the keys all the time? This will increase the traffic, but what about the traffic, where's the guarantee that the message will be received? and that means the server side will need the variable key log for each message, the programmer can get confused with all of this.
 
Urain:

In the beginning, it all comes down to the mailing system itself.
This is where encryption is essential; when the client connects, it sends a connection request

But please tell us what technology is used to send and receive. Where does the server store the data?

I think it's a bit difficult to use signatures. It is enough to have a client's login/password, issued once and checked during requests.
 
sergeev:

OK. Classic scheme.

Why do this? The server can't affect the client anyway.

Why not? It can. Restart the exp, the terminal. No problem.
 
sergeev:
Please tell me which technology is used for sending and receiving the data and where the server stores it.

I don't think it's easy with signatures. It is enough to have just a login/password
The server sends the data to the ftp server and the clients fetch it from there.
 
Urain:
where is the guarantee that the message will be received?
An important question that follows from the answer is what method is used to exchange data?
123456789
New comment