Difference between revisions of "Sockets"
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
== Unix sockets initial support == | == Unix sockets initial support == | ||
| − | Currently we support Unix socket of all kinds, UDP both IPv4 and IPv6 | + | Currently we support Unix socket of all kinds, UDP both IPv4 and IPv6, TCP in Listen and (!) [[TCP connection|Established states]] and Netlink ones. |
| − | The cpt part uses the sock_diag engine to collect extended information about socket | + | The cpt part uses the sock_diag engine to collect extended information about socket, then CRIU uses the files dumping engine to get access to sockets state. |
The restore part of Unix sockets is the most tricky part. Listen sockets are just restored, this is simple. | The restore part of Unix sockets is the most tricky part. Listen sockets are just restored, this is simple. | ||
Revision as of 11:18, 1 December 2014
Unix sockets initial support
Currently we support Unix socket of all kinds, UDP both IPv4 and IPv6, TCP in Listen and (!) Established states and Netlink ones.
The cpt part uses the sock_diag engine to collect extended information about socket, then CRIU uses the files dumping engine to get access to sockets state.
The restore part of Unix sockets is the most tricky part. Listen sockets are just restored, this is simple. Connected sockets are restored like this:
- One end establishes a listening anon socket at the desired descriptor;
- The other end just creates a socket at the desired descriptor;
- All sockets, that are to be connect()-ed call connect. Unix sockets do not block connect() till the accept() time and thus we continue with...
- ... all listening sockets call accept() and ... dup2 the new fd into the accepting end.
There's a problem with this approach -- socket names are not preserved, but looking into our OpenVZ implementation I think this is OK for existing apps.