Bugzilla – Bug 320
getsockname returns a port number in network byte order
Last modified: 2008-11-19 16:38:42 EST
it would make vastly more sense to return a port number in host byte order.
This one is Florian's area.
the API as-is SUCKS: - its unexpected to get an integer filled in in network byte order. - can't just convert the integer internally, since the address is also in network byte order, so we'd have to convert the address inside nsc, too - this API just doesn't work when you want to provide other information that could be stored in some sockaddr (e.g. flow label...) Rationale: Both getpeername and getsockname provided by NSC should be re-done. I've posted a RFC patch that makes both use a struct sockaddr (its not that simple due to network stack <-> host os conversion issues) to the ML: http://mailman.isi.edu/pipermail/ns-developers/2008-October/004878.html This of course means that the port (and address) will still be in network byte order, but at least it will be more obvious then. The advantage is also that it makes things simpler wrt. to other address families that might be supported by future NSC releases.
(In reply to comment #2) > the API as-is SUCKS: > - its unexpected to get an integer filled in in network byte order. > - can't just convert the integer internally, since the address is also > in network byte order, so we'd have to convert the address inside > nsc, too > - this API just doesn't work when you want to provide other information > that could be stored in some sockaddr (e.g. flow label...) > > Rationale: > Both getpeername and getsockname provided by NSC should be re-done. > I've posted a RFC patch that makes both use a struct sockaddr (its not that > simple due to network stack <-> host os conversion issues) to the ML: > http://mailman.isi.edu/pipermail/ns-developers/2008-October/004878.html > > This of course means that the port (and address) will still be in > network byte order, but at least it will be more obvious then. The advantage > is also that it makes things simpler wrt. to other address families that might > be supported by future NSC releases. > This seems like a reasonable solution to me (to just adopt sockaddr in a standard manner at the API)
looks good to me.
Florian has a good fix for this but it hasn't been pushed to NSC's mercurial yet. Florian, would you like to push your fix? I can then do an NSC release and get it incorporated into this version of ns-3.
getpeername/sockname changes have been comitted to nsc repository. Craig, do you want me to commit the ns-3 side change right now or should I wait until sam releases the next nsc version?
Sam asked me to commit the ns-3 side of things as well. Closing bug.
Reopening the bug until we get ns-3-dev depending on a released NSC version with this fix. I've released NSC 0.5.0; I will announce this shortly. This includes this fix and another previous bug fix that is quite critical. We just need a one-line change to ns-3-dev to make it depend on this version (note that if you are using hg you already get the dev version, which includes our fixes).
Created attachment 307 [details] Make ns-3 use the current version of NSC Could somebody please apply this patch to ns-3-dev? We can then close this bug.
Applied, thanks.