[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <31E97136-286D-4EC3-BE6B-7A35B0973EF7@sfc.wide.ad.jp>
Date: Thu, 14 Apr 2011 11:28:58 +0900
From: Michio Honda <micchie@....wide.ad.jp>
To: Wei Yongjun <yjwei@...fujitsu.com>
Cc: netdev@...r.kernel.org, lksctp-developers@...ts.sourceforge.net
Subject: Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
Ah, OK, if so, this patch is unnecessary.
Sorry for missing to read the code.
Thanks,
- Michio
On Apr 14, 2011, at 11:24 , Wei Yongjun wrote:
>
>> Hi,
>>
>> I implemented that functionality for following situations.
>> 1. Suppose two associations A and B directed to different destination that belong to the same endpoint. (one-to-many socket).
>
> Yes, but the addr list of assoc A and B is independent, see
> asoc->base.bind_addr, which is per asoc.
>
> endpoint hold the bind list for new create assoc. when assoc
> is created, the bind list will be copy from ep, by
> sctp_assoc_set_bind_addr_from_ep().
>
>> 2. After the address addition event, A and B will send an ASCONF.
>> 3. Suppose only A receives ASCONF-ACK, and B has not received one yet.
>> 4. In this moment, A can use the new address as the source address for regular chunk, but B can't.
>> 5. But I think both A and B use the new address even after only A receives ASCONF-ACK in current SCTP implementation,
>> This patch achieves that only A uses that new address in this moment.
>>
>> Am I missing something?
>>
>> Thanks,
>> - Michio
>>
>> On Apr 14, 2011, at 10:33 , Wei Yongjun wrote:
>>
>>>
>>>> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
>>>> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
>>> The new adding address is marked SCTP_ADDR_NEW, and cannot use
>>> in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
>>> So, add this valid address list is unnecessary.
>>>
>>> I guess you want to fix the route lookup issue?
>>>
>>> If it is, the only thing we need to fix is the lookup of route. If we can not
>>> found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists