Find the answer to your Linux question:
Results 1 to 8 of 8
Hello, I am trying to migrate a TCP socket in listening mode from one server to another, to achieve this prupose I am copying multiple parameters related to the tcp_sock, ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2014
    Posts
    16

    Question Migrating a TCP socket and copying the contents of sk_buff for queues


    Hello,

    I am trying to migrate a TCP socket in listening mode from one server to another, to achieve this prupose I am copying multiple parameters related to the tcp_sock, and later I copy the contents of the sk_buff for out-of-order queue, write queue and read queue.

    My question is it enough just to copy the following fields of the sk_buff, or not:

    Code:
    skb->data
    skb->cb
    skb->len
    skb->data_len
    skb->mac_len
    skb->hdr_len
    skb->csum
    skb->priority
    skb->ip_summed
    skb->pkt_type
    skb->rxhash
    skb->truesize
    Or do I need to to copy more extra fields?

    For the current implmenetation, copying only these fields work perfectly. But when I try close the socket, the whole machine hangs, so I suppose. there might be something wrong in the data structure I created in the importing side, and I still need more fields to fill.

    The current Linux Kernel Version I am developing on is 3.8.29

  2. #2
    Linux Guru
    Join Date
    Dec 2013
    Location
    Victoria, B.C. Canada
    Posts
    1,658
    You can only have one listening socket per port/address pair. Migrating from one server to another makes no sense in that context - perhaps if you explained in more detail it might be clearer.

  3. #3
    Just Joined!
    Join Date
    May 2014
    Posts
    16

    Smile

    I have two servers running the same application a WebSever on both of them . And one client is connected to the first server and streaming his video from it, later on the client decides to migrate his connection to the second server due to mobility or load balancing. So basically what I am trying to do is to migrate the TCP connection established with the first server to the second server. In this way the client won't feel any interruption in the service, and won't need to re-establish a TCP connection again with the new server. You can think that both servers have the same IP address and running on two different networks, so no need to do any kind of NATing when we migrate the TCP socket.

    I hope this was enough for you.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru
    Join Date
    Dec 2013
    Location
    Victoria, B.C. Canada
    Posts
    1,658
    Someone has to establish the connection if you're going to use TCP. It is a connected protocol. If you want to redirect traffic without the client reconnecting, in the scenario you described, you are going to act as a proxy/tunnel maintaining the connection for the client. This means the load balancer maintains the socket connections to the server and the client and simply passes data through.

  6. #5
    Just Joined!
    Join Date
    May 2014
    Posts
    16
    No need to make the TCP 3 way handshake in my case. When a connection is going to be migrated, the peer that is going to import the migrated connection will create a raw socket first in the listening state, and then pass this socket to a kernel module which will copy the tcp_sock options and different queues contents to this socket. And the client is capable of resuming his video streaming from where he left.

    And as I said, the framework works for me, but I have the problem I mentioned before, the machine hangs when I try to close the socket.

  7. #6
    Linux Guru
    Join Date
    Dec 2013
    Location
    Victoria, B.C. Canada
    Posts
    1,658
    That's quite different from what you described in your previous post. You're really asking about hacking a stream from a kernel module.

    If it's hanging it's likely from dangling locks and pointers.

  8. #7
    Just Joined!
    Join Date
    May 2014
    Posts
    16
    No it is not different at all, I just gave more details how am I migrating a TCP session. And I am not the first one to do that, there are a lot of papers describing different methods for migrating a TCP session.

    But besides that, for my original question. Let's say I want to copy the contents of sk_buff from one server to another. i.e. to recreate the same sk_buff that was in the source server. Do you think the fields I have mentioned are enough to do this or not? For example I am not copying the location of the MAC_Header, Network Header nor Transport Header. Is this correct to do?

  9. #8
    Linux Guru
    Join Date
    Dec 2013
    Location
    Victoria, B.C. Canada
    Posts
    1,658
    If you're trying to implement connection migration or a repair type protocol you seem to be going down the wrong path.

    TCP repair is for fail over control and can all be done from user space as long as your kernel is patched to get the MSS. You still need to create a socket to the new host and involves using an option called TCP_REPAIR mode.

    I've read a number of protocols used for migration - they all involve some negotiation between hosts and client and none involved copying sk_bufs.

    If you've succeeded in passing a connection from one IP address to another without the client knowing then well done. It would seem you are copying enough data.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •