conn: avoid duplicate binding

[OlegHahm]

conn doesn't check if an address-port tuple is already used ("bound" in POSIX terminology) by another thread. One way to do so, would be by storing pointers to all created conn structs and iterate over this list on creation. A potential problem here is that the "owner" of this struct might free it without telling conn, i.e. calling close().

[miri64]

Since most stacks (except GNRC) already provide this functionality (which lead to problems in lwIP tests with conn_.*_sendto() btw, because you can't use sport for an already established connection), I think this is more a task for the stack. For GNRC the fix for that could be way simpler: if nettype TCP or UDP (or any other connection type using ports) then only allow one port as demux_ctx in gnrc_netreg. This makes registration to netreg slightly slower (because for those types the list needs to be iterated), but it shouldn't be more than 3-jump instructions + an extra return.

[OlegHahm]

But binding a port to different addresses on the same host is valid behaviour.

[miri64]

Ah, you're right.

[OlegHahm]

Nevertheless, I think it could be okay for gnrc not to support this.

[miri64]

Especially, since acceptance based on an (addr, port) pair is not something GNRC supports (GNRC lazy-ORs those two, not ANDs them)

[miri64]

Lazy-ORing is not the right word, but I guess you know what I mean.

[miri64]

It checks if the packets destination is on an interface and it checks if the packets destination port has a subscriber, but it does not check if the subscriber is bound to both on the same time.

[OlegHahm]

Yepp, in that case I would be fine with the proposed solution.

[miri64]

#5091 was already moved to the next release so let's move this one too.

[OlegHahm]

Did you put it into the known issue list? (I always prefer to keep issues tagged for the release until they're listed as a known issue in the release notes - if applicable.)

[miri64]

Aren't any issues that aren't solved for the release known issues?

[miri64]

Also, I'm still unsure if this is really a bug and not a feature ;-)

[OlegHahm]

Aren't any issues that aren't solved for the release known issues?

Yes, but you need to track them somehow.

[miri64]

https://github.com/RIOT-OS/RIOT/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+-milestone%3A%22Release+2016.04%22

[OlegHahm]

Exactly this is why I like to keep them tagged for the release until they're noted down in the release notes.

[miri64]

Tagged as what?

[OlegHahm]

"Release 2016.04" in this case

[miri64]

Yes, but what does it mean compared to "Known Issue" (aka issue not solved at release time)?

[OlegHahm]

It's just much easier to list them.

[miri64]

I still don't get, why the search for "All issues, except the ones for Milestone 'Release 2016.04'" isn't exactly the list of known issues and why we have to specially mark them (with the milestone for the release no less).

[OlegHahm]

Usually it should be the other way around: all issues for the Milestone "Release 2016.04" is the list of known issues.

[miri64]

But where go the other issues then?

[OlegHahm]

If it's not tagged for the release, it's not relevant to be listed as a known issue (e.g. a feature request).

[miri64]

I think this way some known issues get lost... You can also exclude labels in the search.

[miri64]

Some known issues for 2015.12 are still marked with the milestone for that release (or even unmarked).

[miri64]

But if this is your workflow, I won't criticize it more. Re-tagged it for this release.

[kaspar030]

If it's not tagged for the release, it's not relevant to be listed as a known issue (e.g. a feature request).

But open issues from one release should all get re-tagged...

[cgundogan]

But open issues from one release should all get re-tagged...

Once they were noted down in the release notes, they can be re-tagged AFAIU.

[miri64]

They can, but some aren't (just click on the known issues in the last release and see)

[cgundogan]

That's because human do err. Old issues should be verified for the current
release, retagged appropriately and added to the known issues.
Am 19.04.2016 20:05 schrieb "Martine Lenders" notifications@github.com:

They can, but some aren't (just click on the known issues in the last
release and see)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#4387 (comment)

[miri64]

yeah, but as far as I can see there are also old issues never mentioned in "known issues" (need to recheck).

[kaspar030]

Maybe we should go back to a "RIOT next" milestone. Everything postponed gets retagged there. Everything that must be fixed can be tagged with a current release milestone. No release with open issues.

... that way we don't get stale issues...

[haukepetersen]

retaggt to 2016.07, I will worry about collecting it for the open issue list...

[kaspar030]

any news?

[miri64]

See #5091...

[kYc0o]

There's no milestone for #5091, so I'll postpone this one.

[miri64]

Fixed in #5772.