471,339 Members | 1,268 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,339 software developers and data experts.

IPAddress::Any vs. IPAddress::Broadcast

ed
What is the difference between IPAddress::Any and IPAddress::Broadcast when
being using by a TCPListener class?
Jul 21 '05 #1
6 6941

"ed" <ed@discussions.microsoft.com> wrote in message
news:32**********************************@microsof t.com...
What is the difference between IPAddress::Any and IPAddress::Broadcast
when
being using by a TCPListener class?


You know, this question just screams that you didn't bother to actually
*look* up the two members. The docs for Any and Broadcast spell out their
differences pretty clearly and TcpListener explicitly references
IPAddress.Any.

You would not ever use Broadcast in a listener, that is the address used to
send a broadcast on the network. IPAddress any means allow connections on
any IP.
Jul 21 '05 #2
ed
Daniel,
while I do appreciate the answer in your second paragraph, there is no need
for the beginning of your first. I may be new to .Net, however I am far from
new to programming (and general technology) and prefer to read as much
documentation as I can before posting on the various development newsgroups.
This comes from the experience of answering countless tech support questions,
many of which would have not occurred had the other party read the
instructions. However, I felt it best to withhold my frustrations and simply
provide the answer to the best of my ability.

All that aside, It seems that you didn't even bother to actually *think*
that maybe I did read the documentation and simply wasn't understanding it to
my own satisfaction.

Again, I do appreciate the second part of your answer. However, the *whole*
answer would have been appreciated had either forgone the side comment or
simply not responded at all.

ed

"Daniel O'Connell [C# MVP]" wrote:

"ed" <ed@discussions.microsoft.com> wrote in message
news:32**********************************@microsof t.com...
What is the difference between IPAddress::Any and IPAddress::Broadcast
when
being using by a TCPListener class?


You know, this question just screams that you didn't bother to actually
*look* up the two members. The docs for Any and Broadcast spell out their
differences pretty clearly and TcpListener explicitly references
IPAddress.Any.

You would not ever use Broadcast in a listener, that is the address used to
send a broadcast on the network. IPAddress any means allow connections on
any IP.

Jul 21 '05 #3
"ed" <ed@discussions.microsoft.com> wrote in message
news:2C**********************************@microsof t.com...
Daniel,
while I do appreciate the answer in your second paragraph, there is no
need
for the beginning of your first. I may be new to .Net, however I am far
from
There is. People not reading tocumentation insult everyone they ask. You
insulted him. He is allowed to point this out.
new to programming (and general technology) and prefer to read as much
documentation as I can before posting on the various development
newsgroups.
But you did not.
This comes from the experience of answering countless tech support
questions,
many of which would have not occurred had the other party read the
instructions. However, I felt it best to withhold my frustrations and
simply
provide the answer to the best of my ability.

All that aside, It seems that you didn't even bother to actually *think*
that maybe I did read the documentation and simply wasn't understanding it
to
my own satisfaction.
Then get a book about how IP works. A small explanation is no replacement
for knowledge.

Again, I do appreciate the second part of your answer. However, the
*whole*
answer would have been appreciated had either forgone the side comment or
simply not responded at all.

ed

"Daniel O'Connell [C# MVP]" wrote:

"ed" <ed@discussions.microsoft.com> wrote in message
news:32**********************************@microsof t.com...
> What is the difference between IPAddress::Any and IPAddress::Broadcast
> when
> being using by a TCPListener class?


You know, this question just screams that you didn't bother to actually
*look* up the two members. The docs for Any and Broadcast spell out their
differences pretty clearly and TcpListener explicitly references
IPAddress.Any.

You would not ever use Broadcast in a listener, that is the address used
to
send a broadcast on the network. IPAddress any means allow connections on
any IP.

Jul 21 '05 #4
ed
Thomas,
while I do appreciate the answer in your second paragraph, there is no
need
for the beginning of your first.

There is. People not reading tocumentation insult everyone they ask. You
insulted him. He is allowed to point this out.

I would agree that had I insulted him he should be allowed to point this
out. Otherwise I wouldn't have exercised my right to do the same in my last
post. But here you seem to make the same assumption (and thus the same
falicy, only to a greater extint) that because I asked the question, that I
therefor did not read the documentation.
new to programming (and general technology) and prefer to read as much
documentation as I can before posting on the various development
newsgroups.


But you did not.

And yet again the assumption that I did not read the docs.
This comes from the experience of answering countless tech support
questions,
many of which would have not occurred had the other party read the
instructions. However, I felt it best to withhold my frustrations and
simply
provide the answer to the best of my ability.

All that aside, It seems that you didn't even bother to actually *think*
that maybe I did read the documentation and simply wasn't understanding it
to
my own satisfaction.


Then get a book about how IP works. A small explanation is no replacement
for knowledge.

First, I completely agree that knowledge is the most important and the most
effective. But only information comes from books. Knowledge/understanding
comes from a mix of books/docs, experience, and dialogue with others. I've
read the docs, I have quite a bit of experience. However, those two alone
was not enough to provide me with the knowledge I needed to make the right
decision for my situation. It other words, sometimes you just have drop the
ego and ask a question. Especially when you have a job to do.

As far as getting a book is concerned, that is a simple cost/benefit
situation to me. I had a simple question that Daniel was able to provide a
sufficient answer for. Spending $40+ on a book to get an answer to such a
simple question would be (at least for the short term) a waste of money that
I could spend elsewhere on the same project.

ed
Jul 21 '05 #5

"ed" <ed@discussions.microsoft.com> wrote in message
news:2C**********************************@microsof t.com...
Daniel,
while I do appreciate the answer in your second paragraph, there is no
need
for the beginning of your first. I may be new to .Net, however I am far
from
new to programming (and general technology) and prefer to read as much
documentation as I can before posting on the various development
newsgroups.
This comes from the experience of answering countless tech support
questions,
many of which would have not occurred had the other party read the
instructions. However, I felt it best to withhold my frustrations and
simply
provide the answer to the best of my ability.

I apologize for mis-interpreting your post. Sadly most people do not read
the docs and expect complex, complete answers and explinations of simple
items, many times ones that really are common konwledge. It gets old and
sometimes the temper flares up. Its unfortunate that you happened to be
someone who did read the docs and simply wrote a message that implied to me
that you didn't.
All that aside, It seems that you didn't even bother to actually *think*
that maybe I did read the documentation and simply wasn't understanding it
to
my own satisfaction.


Of course I did, but you certainly didn't give that impression. I felt the
answer was pretty clearly spelled out in the docs and assumed you never
bothered. Again I apologize.
Jul 21 '05 #6
ed
Daniel,
thank you.

And I appologize for any miscommunications on my part.

sincerely,
ed

"Daniel O'Connell [C# MVP]" wrote:

"ed" <ed@discussions.microsoft.com> wrote in message
news:2C**********************************@microsof t.com...
Daniel,
while I do appreciate the answer in your second paragraph, there is no
need
for the beginning of your first. I may be new to .Net, however I am far
from
new to programming (and general technology) and prefer to read as much
documentation as I can before posting on the various development
newsgroups.
This comes from the experience of answering countless tech support
questions,
many of which would have not occurred had the other party read the
instructions. However, I felt it best to withhold my frustrations and
simply
provide the answer to the best of my ability.


I apologize for mis-interpreting your post. Sadly most people do not read
the docs and expect complex, complete answers and explinations of simple
items, many times ones that really are common konwledge. It gets old and
sometimes the temper flares up. Its unfortunate that you happened to be
someone who did read the docs and simply wrote a message that implied to me
that you didn't.
All that aside, It seems that you didn't even bother to actually *think*
that maybe I did read the documentation and simply wasn't understanding it
to
my own satisfaction.


Of course I did, but you certainly didn't give that impression. I felt the
answer was pretty clearly spelled out in the docs and assumed you never
bothered. Again I apologize.

Jul 21 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Stephan Steiner | last post: by
3 posts views Thread by Ryan Learns Sharp | last post: by
6 posts views Thread by pekspro | last post: by
8 posts views Thread by Frank Esser | last post: by
7 posts views Thread by GTi | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.