Difference between revisions of "Sockets"

From CRIU
Jump to navigation Jump to search
(Fix what sockets are supportred)
m (Link to tcp connection)
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 and TCP in Listen and (!) Established states.
+
Currently we support Unix socket of all kinds, UDP both IPv4 and IPv6 and TCP in Listen and (!) [[TCP connection|Established states]].
  
 
The cpt part uses the sock_diag engine that was merged to Dave recently to
 
The cpt part uses the sock_diag engine that was merged to Dave recently to

Revision as of 21:13, 14 May 2013

Unix sockets initial support

Currently we support Unix socket of all kinds, UDP both IPv4 and IPv6 and TCP in Listen and (!) Established states.

The cpt part uses the sock_diag engine that was merged to Dave recently to 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 restore part is more tricky. 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.

What should be done next

  • socket filter (SK_ATTACH_FILTER)
  • various (ip/tcp level) sockoptions