search

SeattleTestbed / repy_v2

Seattle Testbed's Repy ("Restricted Python") sandbox, version 2
MIT License
12 stars 50 forks source link

Repy V2 semantics regarding openconn #6

Closed choksi81 closed 10 years ago

choksi81 commented 10 years ago

Reported by Danny:

""" I observed one situation in which the semantics of repy was broken. I had a repy server listening bound to IP x. After it was started, I changed the IP address to y. An openconnection on y would raise a connection-refused error. On the other hand, openconnection on x gave

this error:

Uncaught exception!

Following is a full traceback, and a user traceback. The user traceback excludes non-user modules. The most recent call is displayed last. Full debugging traceback: "/tmp/seattle/namespace.py", line 1206, in wrapped_function "/tmp/seattle/emulcomm.py", line 1373, in openconnection "/tmp/seattle/emulcomm.py", line 1190, in _timed_conn_initialize "", line 1, in connect User traceback: "", line 1, in connect Exception (with class 'socket.error'): 113 No route to host

This problem concerns me. The mobility advertises the new IP address whenever it changes, but there is a short gap between the detection of this change and the successfully announcement of the new IP. If a client connects during this gap, it will crash. For now, I can avoid the problem by assuming this won't happen in the evaluation. """

choksi81 commented 10 years ago

Author: mkaplan It appears that this ticket outlines two bugs:

State: After launching Repy, the interfaces IP changes.

Bug 1) It is 'possible' to bind to an IP that previously existed. This throws a 'no route to host' error. Bug 2) Attempting to bind to the new IP throws a connection-refused error.

Bug 1 (possible) Explanation: openconnection() appears to be safe - it first updates the list of interfaces (with update_ip_cache() ), and then checks if it is a valid IP (with _ip_is_allowed() ).

However, there is a boolean flag set in the begginning on Line 105: allow_nonspecified_ips = True

This invalidates the checking done by _ip_is_allowed() (line 122, 139), and blindly returns True each time

Therefore, it is possible to bind to any IP, independent of the previous state. This is currently true for r4888.

choksi81 commented 10 years ago

Author: vijay When an IP address of the system is changed a simple TCP server listening on the system will continue to listen on the old IP address (and port), and the operating system does not appear to notify the socket or the program that its IP address changed. I observed that listening on and then disconnecting the ethernet interface would raise a SocketWouldBlockError (Repyv2).

A possible solution to make the server program learn about the changed IP address would be to run another program or script that checks if the IP address changed and notifies the server program periodically about the change. Another solution would be to include the same piece of code in the server program itself. It appears that the Shims may have this capability.

TCP client behavior when the IP address of the server is changed :

Scenario 1: A client that is connected to the server sends messages until its send buffer is full and then blocks till the connection resumes. Scenario 2: A client that attempts to connect to the servers old IP address timeout. Scenario 3: A client that attempts to connect to the servers new IP address will get a "connection refused error".

UDP:

When an IP address of the system is changed a simple UDP server continue to be binded old IP,port and server will raise a SocketWouldBlockError.