SCCP + SIGTRAN (SUA/M3UA) libraries as well as OsmoSTP
https://osmocom.org/projects/libosmo-sccp
When a client closes and instantaneously re-opens a SCTP socket for an M3UA connection, there is a chance that both the "shutdwon event" (old connection socket becomes readable for sctp event) and the "init event" (listen-fd becomes readable) happen during the same scheduler interval / select() cycle. As there is no guaranteed order by which we call our file descriptor callbacks, it means that we may end up processing then new connection (accept) before we get the notification that the old one is dead. The fact that the fd number of the accept-fd is mostly lower than the fd number of the individual per-client connection actually makes it likely that the order is exactly the opposite of what would feel "logical". As the ASP is identified by the tuple of (src-port, src-ip, dst-port, dst-ip), both the old connection and the new connection map to the same ASP object. So we need to handle this situation gracefully: If we get a new connection for a tuple that we already [think we still] have one, close the old one and use the new. Change-Id: I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa Closes: OS#4625 |
||
---|---|---|
contrib | ||
debian | ||
doc | ||
examples | ||
include | ||
specs | ||
src | ||
stp | ||
tests | ||
.gitignore | ||
.gitreview | ||
COPYING | ||
Doxyfile.in | ||
Makefile.am | ||
TODO-RELEASE | ||
configure.ac | ||
git-version-gen | ||
libosmo-mtp.pc.in | ||
libosmo-sccp.pc.in | ||
libosmo-sigtran.pc.in | ||
libosmo-xua.pc.in | ||
osmoappdesc.py |