All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: linux-sctp@vger.kernel.org
Subject: Re: lksctp question: Association  redundancy
Date: Wed, 04 Feb 2009 16:24:03 +0000	[thread overview]
Message-ID: <4989C123.9070504@hp.com> (raw)

Hi Son

Please address your questions to the sctp list.

Son Le wrote:
> Hi all,
>  We have a situation where we have two nodes that have the same ip address and want to control sctp association redundancy. If the process that owns an association on one node crashes we want to do the following:
> 
> - We do not want to send the ABORT to the far-end by setting the SO_LINGER option. So the far-end at this point still think that this association is still active.
> - The stand by node (it learned some info such verification tag of the association of the other node) will send INIT message using the verification tag (and some other info from previous association) to the same far-end. The far-end can uses these info to reestablish the association on the new node. I assume that the far-end when receive the INIT message from the new node with, is not consider new association but will reestablish the current association
> 

It sounds like you want to trigger an association restart on the remote node.
All you have to do is attempt to initiate the association with the same source,
destination, and address parameters.

You do not need to know remotes verification tag.

> Do you think this strategy would work ? Or do we need to enhance the lksctp stack to support this functionality ?
> 

This strategy might work as long as the remote keeps it's association active.
That depends on how fast the remote detects path and association failures.

-vlad

> Thanks for your help.
> 
> Best regards,
> Son
> 
> -----Original Message-----
> From: Michael Tüxen [mailto:Michael.Tuexen@lurchi.franken.de] 
> Sent: Tuesday, December 02, 2008 11:39 AM
> To: Vlad Yasevich
> Cc: Le, Son (CAR:SI52)
> Subject: Re: lksctp question
> 
> On Dec 2, 2008, at 5:25 PM, Vlad Yasevich wrote:
> 
>> Michael Tüxen wrote:
>>> Hi Vlad,
>>>
>>> on question inside...
>>>
>>> Best regards
>>> Michael
>>>
>>> On Dec 2, 2008, at 3:11 PM, Vlad Yasevich wrote:
>>>
>>>> Son Le wrote:
>>>>> Hi all, Can you help to awnser the below question ?
>>>>>
>>>>>
>>>>> 1.    If an application process owns an SCTP association crashes
>>>>> (traps, or gets
>>>>> killed by other management processes), will the lksctp in the 
>>>>> kernel Shutdown the sctp link gracefully? Or will it just send an 
>>>>> abort to the remote side?
>>>> Depends on the setting of SO_LINGER.  By default, this will cause a 
>>>> graceful shutdown since a "crashed" process is no different from a 
>>>> gracefully exiting process in term of how file descriptors are 
>>>> closed.  If you set SO_LINGER, then any close() on the descriptor 
>>>> will trigger an ABORT.
>>> What if messages are still in the recv buffer? FreeBSD would then 
>>> ABORT the association no matter what SO_LINGER is set to....
>> So, if the application calls close() on the socket even if there is 
>> data there, you will ABORT?
> If there is still data in the recv buffer and the application calls
> close()
> the kernel knows that the application will not get everything. So it sends an ABORT...
>>
>> -vlad
>>
> 


                 reply	other threads:[~2009-02-04 16:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4989C123.9070504@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=linux-sctp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.