Difference between revisions of "Sockets"
(dgram sockets are supported) |
|||
| Line 23: | Line 23: | ||
=== What should be done next === | === What should be done next === | ||
| − | * | + | * socket filter (SK_ATTACH_FILTER) |
| − | + | * various (ip/tcp level) sockoptions | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 19:09, 21 October 2012
Unix sockets initial support
Currently it can only work with stream and dgram sockets, which have no skbs in queues (listening or established -- both work OK). If there are skbs in queue the dumping procedure will fail.
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:
- 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.
What should be done next
- socket filter (SK_ATTACH_FILTER)
- various (ip/tcp level) sockoptions