This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgOn Wed, Jul 06, 2016 at 06:58:40PM +0200, Neels Hofmeyr wrote:
> We should probably:
> * reset --hard our master to vlm/master
> * reset --hard our aper-prefix to aper-prefix-onto-upstream (after testing)
>
> Agreed?
ACK.
> > commit
> d484b0593112222cef3f106da654df07c3d40919 (hash changed after rebases)
> > basically just
> > prints some messages to the log file in case there are association state
> > changes like UP and LOST. This is clearly not the intended behavior.
> >
> > The application should be notified accordintly in such events,
> > particularly in 'connection lost' events that can be communicated in the
> > same way as they can for e.g. TCP sockets.
> >
> > Only after that is resolved, we can merge it to master.
>
> This doesn't look like a lot of work, though I'm not familiar with how exactly
> this should be done.
That's exactly the "hard" question and it probably needs a number of
test cases and trial+error to find out.
A TCP socket is diffent in that once it is closed, it is closed, and the
client can only re-connect, which means a new FD will be accept()ed on
the server.
In SCTP, the association can go UP and DOWN any number of times during
its lifetime, and the file descriptors stay the same.
I'd say the minimum level for getting it merged is that a SUA-using
application on both server and client side continues to work correctly
after any of the events (e.g. an DOWN notification followed by UP
notification). Also, if the socket is SHUTDOWN, the application should
deal with it in a meaningful way. Basically, whatever happens "legally"
on the SCTP side should not make a client or server application stuck in
some weird state.
One could also imagine that any more complete signalling gateway would
actually be interested in all fine-grained event, so having a mechanism
in which any SCTP notifications more or less transparently up to the
user might be a good idea. But that could be an unrelated future
improvement patch.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)