[Twisted-Python] PB and unstable network
I use PB in unstable network. The server remembers the last answer. Client detection disconnected, connected again, makes entry into the system and calls the function returns the last response (get_last_response). The answer, it returns a deferred saved earlier. If somewhere an error cycle repeats. All of this works until the lost communication does not happen at a time when Twisted sends data to a server. As the server in this situation does not receive a first request, and when you call get_last_response client receives the data that has already received. How can I check if an error in the client arrived data to the server or not?
On May 23, 2010, at 11:54 AM, Viktor Klimov wrote:
I use PB in unstable network. The server remembers the last answer. Client detection disconnected, connected again, makes entry into the system and calls the function returns the last response (get_last_response). The answer, it returns a deferred saved earlier. If somewhere an error cycle repeats.
All of this works until the lost communication does not happen at a time when Twisted sends data to a server. As the server in this situation does not receive a first request, and when you call get_last_response client receives the data that has already received.
How can I check if an error in the client arrived data to the server or not?
Hi Viktor, I try not to give people a hard time about bad English, but I am having a hard time reading your message. There are a couple of different things I think you might mean and it would be confusing if I tried to explain them all. Perhaps you could attach some Python code that explains exactly what you mean?
Hi Glyph, sorry for my english. My server.py save last answer(see User.perspectiveMessageReceived). Client when an error occurs(in callRemote) schedule reconnect. After reconnect client call remote method which return last answer. It works if disconnect happened when server send data to client(_server->client_). (try set MyServer.crash_server_to_client to True) But it doesn't work if disconnect happened when client send data to server(_client->server_). Becouse server after reconnect send previous data. It can fix if client be known when error occurs(server->client or client->server). (see comment in Client.net_error). PS for emulate error client->server set Client.crash_client_to_server to True, don't forget set MyServer.crash_server_to_client to False) On Mon, May 24, 2010 at 5:19 AM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On May 23, 2010, at 11:54 AM, Viktor Klimov wrote:
I use PB in unstable network. The server remembers the last answer. Client detection disconnected, connected again, makes entry into the system and calls the function returns the last response (get_last_response). The answer, it returns a deferred saved earlier. If somewhere an error cycle repeats.
All of this works until the lost communication does not happen at a time when Twisted sends data to a server. As the server in this situation does not receive a first request, and when you call get_last_response client receives the data that has already received.
How can I check if an error in the client arrived data to the server or not?
Hi Viktor,
I try not to give people a hard time about bad English, but I am having a hard time reading your message. There are a couple of different things I think you might mean and it would be confusing if I tried to explain them all.
Perhaps you could attach some Python code that explains exactly what you mean?
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
In your case, I would suggest that the server sends some sort of ACK after it has received the payload from client, and the client must send the same kind of ACK in response. Only after that would the server consider operation complete, otherwise it would either inform the client that the previous operation was interrupted midway, or discard the incomplete message completely, thus forcing client to re-send it. Sounds complicated, but I think that's the only reliable way to make sure things don't get duplicated on either server or client. On Tue, May 25, 2010 at 11:34 AM, Viktor Klimov <ploutosss@gmail.com> wrote:
Hi Glyph, sorry for my english.
My server.py save last answer(see User.perspectiveMessageReceived).
Client when an error occurs(in callRemote) schedule reconnect. After reconnect client call remote method which return last answer.
It works if disconnect happened when server send data to client(_server->client_). (try set MyServer.crash_server_to_client to True)
But it doesn't work if disconnect happened when client send data to server(_client->server_). Becouse server after reconnect send previous data. It can fix if client be known when error occurs(server->client or client->server). (see comment in Client.net_error).
PS for emulate error client->server set Client.crash_client_to_server to True, don't forget set MyServer.crash_server_to_client to False)
On Mon, May 24, 2010 at 5:19 AM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On May 23, 2010, at 11:54 AM, Viktor Klimov wrote:
I use PB in unstable network. The server remembers the last answer. Client detection disconnected, connected again, makes entry into the system and calls the function returns the last response (get_last_response). The answer, it returns a deferred saved earlier. If somewhere an error cycle repeats.
All of this works until the lost communication does not happen at a time when Twisted sends data to a server. As the server in this situation does not receive a first request, and when you call get_last_response client receives the data that has already received.
How can I check if an error in the client arrived data to the server or not?
Hi Viktor,
I try not to give people a hard time about bad English, but I am having a hard time reading your message. There are a couple of different things I think you might mean and it would be confusing if I tried to explain them all.
Perhaps you could attach some Python code that explains exactly what you mean?
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
You mean a packet message used in the TCP? Or offer to implement ACK to PB? Maybe someone will point to the literature on network programming in unstable networks? On Tue, May 25, 2010 at 6:41 PM, Yaroslav Fedevych <jaroslaw.fedewicz@gmail.com> wrote:
In your case, I would suggest that the server sends some sort of ACK after it has received the payload from client, and the client must send the same kind of ACK in response. Only after that would the server consider operation complete, otherwise it would either inform the client that the previous operation was interrupted midway, or discard the incomplete message completely, thus forcing client to re-send it.
Sounds complicated, but I think that's the only reliable way to make sure things don't get duplicated on either server or client.
On Tue, May 25, 2010 at 11:34 AM, Viktor Klimov <ploutosss@gmail.com> wrote:
Hi Glyph, sorry for my english.
My server.py save last answer(see User.perspectiveMessageReceived).
Client when an error occurs(in callRemote) schedule reconnect. After reconnect client call remote method which return last answer.
It works if disconnect happened when server send data to client(_server->client_). (try set MyServer.crash_server_to_client to True)
But it doesn't work if disconnect happened when client send data to server(_client->server_). Becouse server after reconnect send previous data. It can fix if client be known when error occurs(server->client or client->server). (see comment in Client.net_error).
PS for emulate error client->server set Client.crash_client_to_server to True, don't forget set MyServer.crash_server_to_client to False)
On Mon, May 24, 2010 at 5:19 AM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On May 23, 2010, at 11:54 AM, Viktor Klimov wrote:
I use PB in unstable network. The server remembers the last answer. Client detection disconnected, connected again, makes entry into the system and calls the function returns the last response (get_last_response). The answer, it returns a deferred saved earlier. If somewhere an error cycle repeats.
All of this works until the lost communication does not happen at a time when Twisted sends data to a server. As the server in this situation does not receive a first request, and when you call get_last_response client receives the data that has already received.
How can I check if an error in the client arrived data to the server or not?
Hi Viktor,
I try not to give people a hard time about bad English, but I am having a hard time reading your message. There are a couple of different things I think you might mean and it would be confusing if I tried to explain them all.
Perhaps you could attach some Python code that explains exactly what you mean?
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On 27 трав. 2010, at 12:45, Viktor Klimov wrote:
You mean a packet message used in the TCP? Or offer to implement ACK to PB?
The latter one. An application-level ack. You only accept a transaction when you have „acked” to your peer that you have the full data payload, and after it acks your ack so that you know your peer won't re-send the same thing over again. Sounds complicated, but at least your peers can both be aware of each others' intentions.
Maybe someone will point to the literature on network programming in unstable networks?
I don't see much difference between the two, except that on an unstable link, you keep trying harder.
participants (4)
-
Glyph Lefkowitz -
Jarosław Fedewicz -
Viktor Klimov -
Yaroslav Fedevych