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: Query
Date: Tue, 12 Jan 2010 20:52:42 +0000	[thread overview]
Message-ID: <4B4CE11A.9090207@hp.com> (raw)
In-Reply-To: <f9a68846db1c.db1cf9a68846@huawei.com>



RahulSrivastava 71616 wrote:
> Thanks!
> If sendmsg succedes like this then how its possible to maintain ordering of messages:
> Consider below order:
>   send1 ----> send2
> 
> send1 was not recieved but send2 was successfully recived by peer on same association. Application gets a notification of send1 (indicating send failed).
> 

No, that will not happen on the same association unless partial reliability is
used.

In the normal scenario (full reliability), if send1 fails, then the association
is destroyed.  The SEND_FAILED event is typically generated in the case of
excessive retransmissions that cause the association to terminate.  There are
a few other times it can be generated, but all those times have to do with
setting a time_to_live on the message.

So, if you are using implicit connect (i.e used the sendto/sendmsg() call
to establish an association), then the steps are these:

1) queue the message to the kernel queue.
2) start association procedure.
   a) if association is successful, send the message.
   b) if association fails, notify the user to association and send failure.

If if you already have an association, the protocol will attempt to deliver
all messages in order.  If the message has already been queued to the kernel,
and the association terminates due to retransmissions, you will get an
association termination notification and a send failed notification.
Any subsequent send calls by the applications will attempt to establish a
new association.

-vlad
> 
> 
> Regards,
> Rahul
> 
> 
> ******************************************************************************************
>  This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
>  *****************************************************************************************
> 
> ----- Original Message -----
> From: Vlad Yasevich <vladislav.yasevich@hp.com>
> Date: Monday, January 11, 2010 10:35 pm
> Subject: Re: Query
> To: RahulSrivastava 71616 <rahuls@huawei.com>
> Cc: linux-sctp@vger.kernel.org
> 
>>
>> RahulSrivastava 71616 wrote:
>>> Hi All,
>>>        I have a query. When using Linux SCTP one-to-many style 
>> sockets sendmsg succedes even though message is not delivered at 
>> the peer. When I ask the socket to wait for notification it gave 
>> send failed in notification.
>>> Is this possible for sendmsg to fail for even for one-to-many 
>> style socket (for peer errors)?
>> Yes.  sendmsg() will return success when the data has successfully 
>> been accepted
>> by the kernel.  However, if peer has problems, you may get a 
>> SEND_FAILEDnotification.
>>
>> This is not linux SCTP specific.  TCP can behave the same way 
>> (minus the
>> notification).
>>
>> -vlad
>>
>>> Regards,
>>> Rahul
>>>
>>>
>>>
>>>
>> ******************************************************************************************>  This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
>>>  
>> *****************************************************************************************> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-
>> sctp" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
> 

  parent reply	other threads:[~2010-01-12 20:52 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-11 14:12 Query RahulSrivastava 71616
2010-01-11 17:05 ` Query Vlad Yasevich
2010-01-12  4:56 ` Query RahulSrivastava 71616
2010-01-12 20:52 ` Vlad Yasevich [this message]
2011-04-05  6:30 ` Query RahulSrivastava 71616
  -- strict thread matches above, loose matches on Subject: below --
2015-07-28  9:27 query Kallumari
2015-07-29 13:12 ` query Kallumari
2015-07-29 15:27   ` query Denis Kenzior
2015-07-29 15:23 ` query Denis Kenzior
2015-07-30  4:03   ` query Kallumari
2015-07-30 12:49   ` query Kallumari
2015-07-30 21:21     ` query Denis Kenzior
2012-01-11 15:51 query Anshul Kundra
2012-01-11 19:54 ` query Eric Sandeen
2012-01-11 14:43 Query Anshul Kundra
2011-05-18 20:42 query Filip, Anotonov
2011-03-16  9:36 Query snmp snmp
     [not found] ` <AANLkTik+c0DvFzkoAzWDXsBSkq4HyHBtA0tuxkLnKu6F@mail.gmail.com>
2011-03-17  9:13   ` Query snmp snmp
2011-03-16  9:35 Query snmp snmp
2011-03-16 11:54 ` Query Alan Cox
2011-03-17 12:04   ` Query snmp snmp
2009-05-22  7:45 Query Vandana Vuthoo
2009-05-22 19:49 ` Query Adrian Pardini
2008-05-02 12:27 query Nandedkar, Rishiraj
2008-05-02 12:51 ` query Stefan Smietanowski
2008-05-02 13:03   ` query Eric Sandeen
2008-05-02 10:42 query Nandedkar, Rishiraj
2008-05-02 12:05 ` query Emmanuel Florac
2008-05-02 12:25 ` query Emmanuel Florac
2008-05-02 10:08 query Nandedkar, Rishiraj
2008-05-02 10:35 ` query Emmanuel Florac
2008-05-02 11:14   ` query Andi Kleen
2006-05-09 11:06 query Chandrashekhar
2006-02-10  4:35 Query aparna misri
2006-02-10 13:30 ` Query Rob Sterenborg
2006-02-10 13:41   ` Query Pablo Sanchez
2006-02-10 13:46   ` Query David Vogt
2006-02-10 14:02     ` Query Rob Sterenborg
2006-02-10 14:05       ` Query David Vogt
2006-02-10 14:28         ` Query Rob Sterenborg
2005-08-09 10:28 query raja
2005-08-09 10:40 ` query Nikhil Dharashivkar
2005-08-09 10:58 ` query Sudheer
2005-05-19  6:24 Query Ashwin Nayak
2005-05-19  6:24 ` Query Philip Edelbrock
2005-05-19  6:24 ` Query Jean Delvare
2004-12-21 12:08 Query Rudresh NB
2004-12-21 12:19 ` Query Artem B. Bityuckiy
2004-12-21 12:42 ` Query Estelle HAMMACHE
2004-12-22  9:05   ` Query Rudresh NB
2004-12-22  9:26     ` Query Estelle HAMMACHE
2004-06-25 13:13 query Manish RATHI
2003-10-23 13:56 query Lever, Charles
2003-10-21 11:09 query Sundareswar Jayakumar
2003-10-22  2:53 ` query Neil Brown
2003-10-22 14:45 ` query Trond Myklebust
2002-10-11 10:46 cross-compiler and stdarg.h Steven Scholz
2002-10-11 11:20 ` Query Anish
2002-10-11 11:43   ` Query Wolfgang Denk
2002-03-06  9:46 Query Hammad Qureshi
2002-03-06  8:07 ` Query Paul Davis
2001-06-02 10:08 query Chanchal Chawla
2001-06-03 14:42 ` query Andreas Dilger

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=4B4CE11A.9090207@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.