Re: Unicast UDP Server
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Fri, 28 Mar 2008 10:49:12 -0700
On Fri, 28 Mar 2008 07:40:24 -0700, O.B. <funkjunk@xxxxxxxxxxxxx> wrote:
If you want to specify a remote address to be used as the default
destination for the UDP socket, use Connect(), not Bind().
But that would require the remote connection to be Bound to that port
to accept connections.
For you to send directly to a remote socket, it has to be bound to a known port, yes. Likewise, for you to send a broadcast to a remote socket, it has to be bound to a known port. And either case, you'd send your datagram to that known port. You can either use Connect() to specify the remote address (including the broadcast IP address and the target port), or you can explicitly provide the address each time you send.
But Bind() has nothing to do with any of that.
Here is the dilemma. We have a user that has
other commercial software that is only capable of running their
sockets as client UDP broadcast connections on a fixed port.
There's no such thing as a "UDP connection". I'll just ignore the word "connection" there.
As far as receiving broadcasts goes...if your clients are for some reason required to listen for broadcasts only on a specific port, then you'll have to broadcast on that port.
I don't really understand your statement that the software "that is only capable of running their sockets as client UDP broadcast". If a socket can receive a broadcast, it can also receive a datagram sent directly to it. So the stipulation that broadcasts must be involved seems odd to me.
Finally, I'm assuming this is all on the same network segment or segments connected such that the broadcasts are routed properly to the recipient.
On our
end, the user wants the ability to open two UDP servers both on the
same port, but for each one to filter based on the IP that is sending
data. I was hoping that it would be possible to do this in the
connection setup rather than having our asynchronous receive callback
do the filtering.
Again: with UDP there's no such thing as a connection. That said, you _can_ use the Connect() method to specify a remote address from which datagrams may be received, discarding datagrams sent by any other address. It doesn't create a connection, but it does do what you seem to want it to do.
Keeping in mind, however, that you cannot have two UDP sockets bound to the same local address. If you've got two different computers, or at least two different adapters on the same computer, this should be fine. But if you've got a single network adapter on a single computer, you can't reliably have two UDP servers bound to the same port (you can use the "reuse address" option, but when you do that, the OS provides no guarantess as to which socket will receive which datagram).
With that said, what is the point of binding to a specific address if
it isn't allowed?
If it weren't allowed, you're right...there wouldn't be any point in binding. But it is allowed. It just does something different than what you seem to think it does.
Bind() specifies the _local_ endpoint for the socket. It essentially labels the socket you're operating with, so that other sockets can communicate with it. If you specify an IP address, it must be a valid IP address for the local host. You may specify IPAddress.Any for the address, in which case the OS will choose an adapter (for client sockets) or listen on all adapters (for server sockets).
Connect(), on the other hand, specifies the _remote_ endpoint for the socket. If you specify an IP address, it must be a valid IP address for the _other_ end of your communications. This could in fact be your local host's IP address, but _only_ if you are communicating with another socket on the same network adapter/computer. In any case, it doesn't label anything...it simply sets up the link between the socket you're operating with and some remote socket. For a TCP socket an actual connection is created, but for a UDP socket all it does is set some internal state for the local socket that the OS then uses when you call Send() and Receive().
By the way...IMHO, you shouldn't be messing with the socket buffer sizes
unless you have already gotten everything else working, you know exactly
what you're doing, _and_ you have run into some problem that requires you
to change the default buffer sizes.
We started off with defaults and lost too many packets. 75 MB ended
up being a good number. Most of our machines are running with 4 GB or
more of memory, so it isn't an issue.
Okay. If you're running all of this on a LAN, over a gigabit network, in an extremely high-volume situation, that _might_ be reasonable. Otherwise, that's an awful lot of data to pile up without your servers being able to process it. If one or more of those descriptions don't apply to your situation, you could (and should IMHO) probably fix the issue in a more appropriate way (i.e. just fixing the code so that it's more responsive).
Pete
.
- Follow-Ups:
- Re: Unicast UDP Server
- From: O.B.
- Re: Unicast UDP Server
- References:
- Unicast UDP Server
- From: O.B.
- Re: Unicast UDP Server
- From: Peter Duniho
- Re: Unicast UDP Server
- From: O.B.
- Unicast UDP Server
- Prev by Date: paypal sell air jordan,AF1,dunk,air max,shox,puma,prada www.cnbbiz.com
- Next by Date: Re: windows forms - transparence question
- Previous by thread: Re: Unicast UDP Server
- Next by thread: Re: Unicast UDP Server
- Index(es):
Relevant Pages
|
