how to know local port used in an udp client ?

[Greg2fs]

Hello, I know the port used by my udp client to forward it using upnp.
How to do ?

Thanks

 

[Kenny McCormack]

Hello, I know the port used by my udp client to forward it using upnp.
How to do ?

Thanks

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

--
Useful clc-related links:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

 

[Greg2fs]

Off topic.  Not portable.  Cant discuss it here.  Blah, blah, blah.

--
Useful clc-related links:

   http://en.wikipedia.org/wiki/Aspergers
   http://en.wikipedia.org/wiki/Clique
   http://en.wikipedia.org/wiki/C_programming_language

Isn't it a c group ? I don't understand...

 

[Kenny McCormack]

Isn't it a c group ? I don't understand...

It was a pre-emptive strike. As you will soon find out, this newsgroup
has been taken over by a bunch of buttheads who have this totally weird
notion about what the C language is. They will be along any second now
to tell you the same thing I just told you, but in much more patronizing
and juvenile tones.

In other words, I was joking. They will not be.

And, welcome to CLC. We hope you enjoy your stay!

 

[Barry Schwarz]

Isn't it a c group ? I don't understand...

If you hang around long enough you will learn two things at least:

Who enjoys being obnoxious and disruptive.

That this is group about the C language, not about how to use
programs written in C or how to use extensions to the language to
perform system specific tasks. Since the C language as defined in the
ISO standard has no support for ports, udp, or upnp, your question
falls into the latter category. You will get much better responses if
you post the question in a group that deals with upnp.

 

[Antoninus Twink]

Hello, I know the port used by my udp client to forward it using upnp.
How to do ?

Use getsockname(2).

Or, choose which port to bind to yourself instead of letting the socket
layer choose an available ephemeral port.

Please ignore the trolls who seek to disrupt this newsgroup by
restricting discussion of valid C programming topics like networking.

 

[Antoninus Twink]

This group is about all C related programming as defined in its
founding charter.

Exactly.

It is interesting that none of the topicality taliban have the courage
of their convictions to set up comp.lang.iso-c or comp.lang.c.iso and
see just how popular a group restricted to ISO C would be...

 

[Seebs]

Isn't it a c group ? I don't understand...

The C language doesn't have sockets. Some specific implementations have
sockets, but the way you use sockets varies widely from one system to another,
so there's no generic answer. If you're on a Unix-derived system, you can
probably get good answers in comp.unix.programmer, but those same answers will
be worthless to you if you're on Windows...

-s

 

[Antoninus Twink]

The C language doesn't have sockets.

Nonsense.

Are you trying to argue that

int socket(int domain, int type, int protocol);

is not a C API? If so, I call bullshit.

My advice would be to leave that sort of stupidity to Heathfield and
Thomson.

If you're on a Unix-derived system, you can probably get good answers
in comp.unix.programmer, but those same answers will be worthless to
you if you're on Windows...

This is nonsense. Sockets are very portable - Windows also uses
Berkeley sockets.

This is a great example of something that is indisputably better
discussed in a more general group like clc, because it *isn't* specific
to Windows or to *nix.

 

[Kaz Kylheku]

Use getsockname(2).

Note that getsockname may return zero for an empehemeral socket.
It's not a portable way of finding the actual port obtained.

Or, choose which port to bind to yourself instead of letting the socket
layer choose an available ephemeral port.

It's best to implement you write your own loop to scan the port space
for an available port, if you want a de-facto ephemeral port /and/ know
what it is in a portable way rather than relying on getsockname.
Moreover, you can control the allocation range this way, which you must
do if your client is to have any hope of getting out through some
firewalls.

 

[Kenny McCormack]

Nonsense.

Are you trying to argue that

int socket(int domain, int type, int protocol);

is not a C API? If so, I call bullshit.

My advice would be to leave that sort of stupidity to Heathfield and
Thomson.

To be fair, their position *is* consistent and logical, given their
definition(s). It's just that their definition(s) is/are ludicrous.

 

[Kenny McCormack]

Is this Seebs guy a Heathfield sock? He has all the mannerisms and
annoying starchiness.

To be fair, I don't *think* he is a sock. But he (Petey) certainly has
found a friend...!

I think it is fairly well documented that they suffer from the same (or
very similar) neuroses.

 

[Beej Jorgensen]

Note the size of this "keep it on topic" subthread compared to that of
the subthread that contains the actual answer.

With a cure like this, who needs a disease?

-Beej

 

[Nobody]

This is nonsense. Sockets are very portable - Windows also uses
Berkeley sockets.

Windows has something which looks superficially similar to the BSD
socket functions.

However, BSD sockets aren't a stand-alone API, but extensions to the Unix
API. The value returned from socket() (and accept()) is a file descriptor
(a small, non-negative integer, so you can use it as an array index),
which can be passed to read(), write(), fdopen(), close(), dup() etc.

 

[Greg2fs]

I don't use to talk on newsgroups from long but with all these answers
I think I will continue, and it seems than this newsgroup correspond
to my request as I get answers...

I din't know I could use bind for a client, but it works, this way I
choose the port I want, thanks !

 

[Kenny McCormack]

Note the size of this "keep it on topic" subthread compared to that of
the subthread that contains the actual answer.

With a cure like this, who needs a disease?

-Beej

That's exactly my point. First of all, by posting my little thing that
started the sub-thread, I was just doing, virtually word-for-word, what
the regs would do. So, I am simply performing a service; saving them
the trouble. Second, that's how it always happens. Search the
archives. You will find innumerable, virtually endless, threads about
topicality. On and on.

Their stated goal is to minimize the traffic. Yet, they pretend to be
blithely unaware of the fact that if they either a) just ignored the
threads they don't wish to respond to or b) just gave the d*** answer,
the traffic would be much less. Preferably the later, of course, but
certainly the former is preferable to these topicality rants.

 

[Keith Thompson]

I don't use to talk on newsgroups from long but with all these answers
I think I will continue, and it seems than this newsgroup correspond
to my request as I get answers...

As several people have tried to tell you, on the particular topic
you're asking about you're likely to get more and better answers
in comp.unix.programmer.

Your question really isn't about the C language, which is what we
(try to) discuss here. There are C implementations that don't
support sockets, and there are implementations of sockets for
languages other than C.

[...]

 

[Keith Thompson]

As several people have tried to tell you, on the particular topic
you're asking about you're likely to get more and better answers
in comp.unix.programmer.

Richard Heathfield says that Windows has good support for the
Berkeley Sockets API, so comp.os.ms-windows.programmer.win32 might
also be a good source of information.

Your question really isn't about the C language, which is what we
(try to) discuss here. There are C implementations that don't
support sockets, and there are implementations of sockets for
languages other than C.

[...]

 

[Chad]

Nonsense.

Are you trying to argue that

int socket(int domain, int type, int protocol);

is not a C API? If so, I call bullshit.

Let me quote Dr. Richtie

"C offers only straightforward, single-thread control flow: tests,
loops, grouping, and subprograms, but not multiprogramming, parallel
operations, synchronization, or coroutines."

 

[Chad]

Let me quote Dr. Richtie

"C offers only straightforward, single-thread control flow: tests,
loops, grouping, and subprograms, but not multiprogramming, parallel
operations, synchronization, or coroutines."

Eeerrr Dr. Ritchie.