[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae526ae5437349e9bbfdf97286603d94@AcuMS.aculab.com>
Date: Mon, 14 Oct 2019 08:49:54 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Xin Long' <lucien.xin@...il.com>,
Neil Horman <nhorman@...driver.com>
CC: network dev <netdev@...r.kernel.org>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [PATCHv2 net-next 3/5] sctp: add
SCTP_EXPOSE_POTENTIALLY_FAILED_STATE sockopt
From: Xin Long <lucien.xin@...il.com>
> Sent: 14 October 2019 09:37
...
> RFC actually keeps adding new notifications,
That RFC keeps moving the goalposts.
Even the structures are guaranteed to have holes.
> and a user shouldn't expect
> the specific notifications coming in some exact orders. They should just
> ignore it and wait until the ones they expect. I don't think some users
> would abort its application when getting an unexpected notification.
I've an example of exactly 1 application.
It uses TCP-style sockets (and will work over TCP).
It does getsockopt(SCTP_EVENTS), sets sctp_association_event, then setsockopt().
Any MSG_NOTIFICATION is assumed to be the a connection reset (enabled above)
and treated as an inwards disconnect.
So any unexpected notification will kill the connection.
I suspect it isn't the only one..
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists