Difference between revisions of "Sockets"

From CRIU
Jump to navigation Jump to search
(Created page with "== Unix sockets initial support == Currently it can only work with stream sockets, which have no skbs in queues (listening or established -- both work OK). The cpt part uses th...")
 
m
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Unix sockets initial support ==
 
== Unix sockets initial support ==
  
Currently it can only work with stream sockets, which have no skbs in queues
+
Currently we support Unix socket of all kinds, UDP both IPv4 and IPv6, TCP in Listen and (!) [[TCP connection|Established states]] and Netlink ones.
(listening or established -- both work OK).
 
  
The cpt part uses the sock_diag engine that was merged to Dave recently to
+
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.
collect sockets. Then it dumps sockets by checking the filesystem ID of a
 
failed-to-open through /proc/pid/fd descriptors (sockets do not allow for
 
such tricks with opens through proc) against SOCKFS_TYPE.
 
  
The rst part is more tricky. 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.
 
Connected sockets are restored like this:
 
Connected sockets are restored like this:
  
Line 17: Line 13:
 
# ... all listening sockets call accept() and ... dup2 the new fd into the accepting end.
 
# ... 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
+
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.
looking into our OpenVZ implementation I think this is OK for existing apps.
 
  
=== What should be done next ===
+
[[Category:Under the hood]]
 
+
[[Category:Sockets]]
* Need to merge the file IDs patches in our tree and make Andrey to support files sharing. This will solve the
 
 
 
<code>
 
sk = socket();
 
fork();
 
</code>
 
 
 
case. Currently it simply doesn't work :(
 
* Need to add support for DGRAM sockets -- I wrote comment how to do it in the can_dump_unix_sk()
 
* Need to add support for in-flight connections
 
* Implement support for UDP sockets (quite simple)
 
* Implement support for listening TCP sockets (also not very complex)
 
* Implement support for connected TCP scokets (hard one, Tejun's patches are not very good for this from my POV)
 

Latest revision as of 10:16, 21 September 2016

Unix sockets initial support[edit]

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:

  1. One end establishes a listening anon socket at the desired descriptor;
  2. The other end just creates a socket at the desired descriptor;
  3. 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...
  4. ... 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.