 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 15 May 2010 13:02:58 -0700, Darren New wrote:
> Jim Henderson wrote:
>>> If you have one cable coming into the university campus, and a network
>>> for each building, the router is going to have to send the packets to
>>> each building, duplicating the packets, regardless of how "aware"
>>> anyone is.
>>
>> Yes, but that's not a 1:1 transmission (compared to the receiving
>> clients).
>
> I don't know what you mean.
It's not one sender to one receiver. It's one sender to many receivers.
> For one thing, modern ethernet (the kind that goes over CAT5 instead of
> coax) is indeed 1:1 on every part of the network. Nothing I send from my
> computer to yours does not go through the router.
Not necessarily true if it's a local subnet. But even if it is across
routers, so what? The router is just setting up a multicast domain for
the downstream network, which may include another router that does the
same thing.
> You need to duplicate the packets at least once per physical wire. Same
> as any network. IP doesn't force you to duplicate anything less.
True.
> Granted, if you're broadcasting from one point, the broadcaster only has
> to send one packet per physical connection regardless of the number of
> recipients. But that's the same with ISDN and all those technologies
> too. You call into a conference bridge and the bridge duplicates the
> data as necessary. You're not sending out the same data once for each
> receiver there either.
That's also the point; the amount of traffic sent by the sender is
significantly reduced; the switches also typically have logic so they
don't have to fill their buffers with multiple copies of the same data
(for those that have a buffer).
> Firstly, if your subnet isn't broadcast, it doesn't save you any
> bandwidth. The router still needs to duplicate all the packets. If your
> subnet *does* support broadcast (like coax ethernet, or alohanet, or
> something like that) then sure, you can broadcast to everyone, but
> that's because *any* transmission goes to everyone, taking up your
> bandwidth even if it's not addressed to you.
I think there may be a conflation of "broadcast" and "multicast" here.
> Broadcast networks tend to be very small, and they tend to not allow two
> conversations at once. You're not saving bandwidth by broadcasting.
> You're just using it more efficiently. A targeted communication on a
> broadcast network still takes up everyone's bandwidth. They just ignore
> it. Multicast on a broadcast network isn't saving bandwidth as much as
> it's not wasting bandwidth.
Small relative to the size of the Internet, sure. Small relative to the
size of a given network, maybe not so much.
That last sentence is just semantics, though.
> Wireless is about the only common broadcast IP-based network still
> around, tho, exactly because it's so bandwidth-inefficient and
> impossible to squelch when something goes wrong.
I assume you're talking about 802.11 networks; some wireless networking
technologies implement CSMA-CA while others do CSMA-CD; the latter is
much more efficient but requires hardware that is capable of listening;
in a spread-spectrum implementation (which most 802.11 networks are),
CSMA-CA is more common but the DSS implementations mean that there's much
less chance of a collision (that's part of the point of that type of
implementation).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Sat, 15 May 2010 13:02:58 -0700, Darren New wrote:
>
>> Jim Henderson wrote:
>>>> If you have one cable coming into the university campus, and a network
>>>> for each building, the router is going to have to send the packets to
>>>> each building, duplicating the packets, regardless of how "aware"
>>>> anyone is.
>>> Yes, but that's not a 1:1 transmission (compared to the receiving
>>> clients).
>> I don't know what you mean.
>
> It's not one sender to one receiver. It's one sender to many receivers.
Right. The question isn't how many senders and receivers there are. The
question is whether you're duplicating packets.
>> For one thing, modern ethernet (the kind that goes over CAT5 instead of
>> coax) is indeed 1:1 on every part of the network. Nothing I send from my
>> computer to yours does not go through the router.
>
> Not necessarily true if it's a local subnet.
Uh, yes. There's nothing that's going to go over this cat5 wire that doesn't
go to the other end of the wire. If your PC is plugged into your
router/switch, and your other PC is plugged into your router/switch, then
talking between the PCs goes thru the router/switch.
The only difference would be if you have (a) only two PCs on the network, at
which point multicast is irrelevant, or (b) you have a hub, at which point
the hub is still duplicating packets for every wire, except it's doing it
indiscriminately.
> But even if it is across
> routers, so what? The router is just setting up a multicast domain for
> the downstream network, which may include another router that does the
> same thing.
I think at this point you may have forgotten why we're discussing this.
The contention was that things like ATM and ISDN are "point to point" while
IP somehow isn't. My contention is that any network physically wired
anything close to what ATM and ISDN does is also point to point, and that
most IP networks other than wireless are of the same sort of topology as ATM
and ISDN. (And maybe wireless, too. I don't know enough to know whether one
node can send to the other without the AP repeating it.)
>> You need to duplicate the packets at least once per physical wire. Same
>> as any network. IP doesn't force you to duplicate anything less.
>
> True.
That's my point. IP is still point-to-point, by necessity, when you don't
have a broadcast network.
When you *do* have a broadcast network, unless you do something really funky
(unlike, say, coax ethernet), all the nodes can be conceptually treated as
one node, because they can't talk at the same time, they all see the same
data, they don't get all the bandwidth to themselves, etc. And that hasn't
anything to do with IP. IP multicast doesn't route packets to a specific
machine. It routes them to a specific broadcast subnet, if there is one. If
I'm on a segment with someone receiving multicast, I have no way *not* to
receive that, and it can saturate my bandwidth even tho I'm uninterested.
>> Granted, if you're broadcasting from one point, the broadcaster only has
>> to send one packet per physical connection regardless of the number of
>> recipients. But that's the same with ISDN and all those technologies
>> too. You call into a conference bridge and the bridge duplicates the
>> data as necessary. You're not sending out the same data once for each
>> receiver there either.
>
> That's also the point; the amount of traffic sent by the sender is
> significantly reduced;
When I'm on a conference call via ISDN, I'm only sending one copy of each
byte. I'm not the one doing the duplication. The ISDN router (known as the
conference bridge) is doing the duplication, just like in IP.
> the switches also typically have logic so they
> don't have to fill their buffers with multiple copies of the same data
> (for those that have a buffer).
True, but now we're talking about something far below the level of IP.
>> Firstly, if your subnet isn't broadcast, it doesn't save you any
>> bandwidth. The router still needs to duplicate all the packets. If your
>> subnet *does* support broadcast (like coax ethernet, or alohanet, or
>> something like that) then sure, you can broadcast to everyone, but
>> that's because *any* transmission goes to everyone, taking up your
>> bandwidth even if it's not addressed to you.
>
> I think there may be a conflation of "broadcast" and "multicast" here.
Nope. I'm saying there are two physical networking possibilities: broadcast,
and unicast. Either everyone gets the signal on a broadcast network, or only
one person gets the signal on a unicast network. Coax ethernet is
broadcast. CAT5 ethernet is unicast.
The only place that multicast saves bandwidth is on a unicast network (like
between routers) where nobody downstream of the receiver wants to receive
the data. If you have a separate wire to each PC with bandwidth dedicated to
that PC, multicast is 1:1 on any given segment of the network.
>
>> Broadcast networks tend to be very small, and they tend to not allow two
>> conversations at once. You're not saving bandwidth by broadcasting.
>> You're just using it more efficiently. A targeted communication on a
>> broadcast network still takes up everyone's bandwidth. They just ignore
>> it. Multicast on a broadcast network isn't saving bandwidth as much as
>> it's not wasting bandwidth.
>
> Small relative to the size of the Internet, sure. Small relative to the
> size of a given network, maybe not so much.
>
> That last sentence is just semantics, though.
By that I mean that multicast on a broadcast network doesn't needlessly send
the same packet multiple times. But neither does something like ATM or ISDN.
>> Wireless is about the only common broadcast IP-based network still
>> around, tho, exactly because it's so bandwidth-inefficient and
>> impossible to squelch when something goes wrong.
>
> I assume you're talking about 802.11 networks;
Yes, the kind that carry IP via broadcast. Something like IP over CDMA or
GSM is much closer to having a wired connection than a broadcast connection,
since nearby nodes aren't listening to you.
> some wireless networking
> technologies implement CSMA-CA while others do CSMA-CD; the latter is
> much more efficient but requires hardware that is capable of listening;
> in a spread-spectrum implementation (which most 802.11 networks are),
> CSMA-CA is more common but the DSS implementations mean that there's much
> less chance of a collision (that's part of the point of that type of
> implementation).
Sure. But if I have a 10Mbps coax, or a 54Mbps 802.11g, I'm sharing that
with everyone else on that network. If I can hear everything coming out of
the router and I have to wait for everyone else to stop transmitting before
I can, then having multicast not transmit duplicates isn't "saving"
bandwidth. It's taking up my bandwidth whether I'm listening to it or not.
If I have a 9Mbps stream coming in, my coax ethernet network is going to be
slow whether I'm watching video or not. What it *does* do is not send it
twice when everyone interested has already heard it. That's what I was
talking about.
However, I strongly suspect that none of this discussion has anything to do
with whatever Andrew meant when he said IP isn't 1:1 like ISDN is.
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Small relative to the size of the Internet, sure. Small relative to the
> size of a given network, maybe not so much.
I meant small physically. Rarely does a broadcast network extend over more
than (say) one building. Not if you're talking about a 2-way broadcast.
Maybe cable IP systems? I don't know how they work on the cable, whether
it's closer to TDMA or closer to CDMA or what. Clearly it's not isochronous,
so you get the bandwidth you ask for if it's available. Thinking on it, I'm
guessing at least the cable network for the local neighborhood is probably
one big broadcast tree, so yea, bigger than I was thinking.
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> My point is that ISDN is a point-to-point system, so it doesn't have a
> concept of network addresses.
WTF? What are you smoking? And can I have some?
http://en.wikipedia.org/wiki/ISDN
> Having a global network without addresses doesn't really work.
You *have* heard of phone numbers, haven't you?
> And that's kind of my point: All the other network systems were designed
> for networks that are "small", where it's feasible to keep track of all
> the addresses by hand. None of them really supported having several
> networks connected together, managed independently.
So, when you make a phone call to someone in the USA, you think there's one
group of people managing the undersea cable, the wire going into your
building, and the cell phone towers talking to the cell phone in the USA?
When you see a phone number that starts +1 or +43 or something like that,
what do you think that means?
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 May 2010 10:12:20 -0700, Darren New wrote:
> Jim Henderson wrote:
>> Small relative to the size of the Internet, sure. Small relative to
>> the size of a given network, maybe not so much.
>
> I meant small physically. Rarely does a broadcast network extend over
> more than (say) one building. Not if you're talking about a 2-way
> broadcast.
What do you mean by "2-way broadcast"?
> Maybe cable IP systems? I don't know how they work on the cable, whether
> it's closer to TDMA or closer to CDMA or what. Clearly it's not
> isochronous, so you get the bandwidth you ask for if it's available.
> Thinking on it, I'm guessing at least the cable network for the local
> neighborhood is probably one big broadcast tree, so yea, bigger than I
> was thinking.
Yes, but from a standpoint of multicast, there again, you get some
savings (and increased scalability). I imagine (but don't know for sure)
that cable uses some sort of multicast scheme (though probably not
multicast over IP) so there isn't a bottleneck at the transmitting end of
things; all people who are watching channel 657 are likely part of a
multicast group of some sort, otherwise you'd hit xmit bandwidth
limitations when a large number of people start watching TV all at once.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 May 2010 10:07:52 -0700, Darren New wrote:
> Jim Henderson wrote:
>> On Sat, 15 May 2010 13:02:58 -0700, Darren New wrote:
>>
>>> Jim Henderson wrote:
>>>>> If you have one cable coming into the university campus, and a
>>>>> network for each building, the router is going to have to send the
>>>>> packets to each building, duplicating the packets, regardless of how
>>>>> "aware" anyone is.
>>>> Yes, but that's not a 1:1 transmission (compared to the receiving
>>>> clients).
>>> I don't know what you mean.
>>
>> It's not one sender to one receiver. It's one sender to many
>> receivers.
>
> Right. The question isn't how many senders and receivers there are. The
> question is whether you're duplicating packets.
Yes, and you would duplicate packets when repeating to a different
subnet, sure. That doesn't mean the bandwidth savings disappear when you
introduce a router to the picture.
>>> For one thing, modern ethernet (the kind that goes over CAT5 instead
>>> of coax) is indeed 1:1 on every part of the network. Nothing I send
>>> from my computer to yours does not go through the router.
>>
>> Not necessarily true if it's a local subnet.
>
> Uh, yes. There's nothing that's going to go over this cat5 wire that
> doesn't go to the other end of the wire. If your PC is plugged into your
> router/switch, and your other PC is plugged into your router/switch,
> then talking between the PCs goes thru the router/switch.
Yes, true.
> The only difference would be if you have (a) only two PCs on the
> network, at which point multicast is irrelevant, or (b) you have a hub,
> at which point the hub is still duplicating packets for every wire,
> except it's doing it indiscriminately.
True in both cases.
>> But even if it is across
>> routers, so what? The router is just setting up a multicast domain for
>> the downstream network, which may include another router that does the
>> same thing.
>
> I think at this point you may have forgotten why we're discussing this.
Perhaps, or perhaps the discussion mutated. :-)
> The contention was that things like ATM and ISDN are "point to point"
> while IP somehow isn't. My contention is that any network physically
> wired anything close to what ATM and ISDN does is also point to point,
> and that most IP networks other than wireless are of the same sort of
> topology as ATM and ISDN. (And maybe wireless, too. I don't know enough
> to know whether one node can send to the other without the AP repeating
> it.)
I was simply pointing out that multicast (in particular) isn't
necessarily point-to-point from an IP standpoint. I think you may be
talking at a lower level in the OSI stack than IP that it is, and I
couldn't disagree with that, certainly.
>>> You need to duplicate the packets at least once per physical wire.
>>> Same as any network. IP doesn't force you to duplicate anything less.
>>
>> True.
>
> That's my point. IP is still point-to-point, by necessity, when you
> don't have a broadcast network.
This is where I think you're talking at the physical or network layer,
not the transport layer.
> When you *do* have a broadcast network, unless you do something really
> funky (unlike, say, coax ethernet), all the nodes can be conceptually
> treated as one node, because they can't talk at the same time, they all
> see the same data, they don't get all the bandwidth to themselves, etc.
> And that hasn't anything to do with IP. IP multicast doesn't route
> packets to a specific machine. It routes them to a specific broadcast
> subnet, if there is one. If I'm on a segment with someone receiving
> multicast, I have no way *not* to receive that, and it can saturate my
> bandwidth even tho I'm uninterested.
That's not how multicast works, to my understanding. You subscribe to
the multicast - unless the switch (a) isn't a switch, or (b) isn't
multicast aware, you're right; but if you are on a segment with someone
who receives a multicast and the network hardware understands which ports
to send the multicast data to, then no, you don't see the packets because
you're not subscribed to the multicast.
> When I'm on a conference call via ISDN, I'm only sending one copy of
> each byte. I'm not the one doing the duplication.
Right.
> The ISDN router (known
> as the conference bridge) is doing the duplication, just like in IP.
Depends on whether you're talking unicast to *each* destination node or
multicast IP. Therein lies the difference (and the bandwidth savings).
In a multicast scenario, at the transport layer, the switch isn't
"duplicating" the packet, it's forwarding it (which may be a semantic
debate).
>> the switches also typically have logic so they don't have to fill their
>> buffers with multiple copies of the same data (for those that have a
>> buffer).
>
> True, but now we're talking about something far below the level of IP.
Not in a Layer3 switch we're not. ;-)
>>> Firstly, if your subnet isn't broadcast, it doesn't save you any
>>> bandwidth. The router still needs to duplicate all the packets. If
>>> your subnet *does* support broadcast (like coax ethernet, or alohanet,
>>> or something like that) then sure, you can broadcast to everyone, but
>>> that's because *any* transmission goes to everyone, taking up your
>>> bandwidth even if it's not addressed to you.
>>
>> I think there may be a conflation of "broadcast" and "multicast" here.
>
> Nope. I'm saying there are two physical networking possibilities:
> broadcast, and unicast. Either everyone gets the signal on a broadcast
> network, or only one person gets the signal on a unicast network. Coax
> ethernet is broadcast. CAT5 ethernet is unicast.
Yes, physical layer (or network layer), not transport layer. It feels
like you're conflating the two.
> The only place that multicast saves bandwidth is on a unicast network
> (like between routers) where nobody downstream of the receiver wants to
> receive the data. If you have a separate wire to each PC with bandwidth
> dedicated to that PC, multicast is 1:1 on any given segment of the
> network.
The destination "1" is a single multicast address that the specific
targets subscribe to - that's what makes it not 1:1, but 1:many.
>>> Broadcast networks tend to be very small, and they tend to not allow
>>> two conversations at once. You're not saving bandwidth by
>>> broadcasting. You're just using it more efficiently. A targeted
>>> communication on a broadcast network still takes up everyone's
>>> bandwidth. They just ignore it. Multicast on a broadcast network isn't
>>> saving bandwidth as much as it's not wasting bandwidth.
>>
>> Small relative to the size of the Internet, sure. Small relative to
>> the size of a given network, maybe not so much.
>>
>> That last sentence is just semantics, though.
>
> By that I mean that multicast on a broadcast network doesn't needlessly
> send the same packet multiple times. But neither does something like ATM
> or ISDN.
There again, though, mixing up physical/network layer with transport
layer.
>>> Wireless is about the only common broadcast IP-based network still
>>> around, tho, exactly because it's so bandwidth-inefficient and
>>> impossible to squelch when something goes wrong.
>>
>> I assume you're talking about 802.11 networks;
>
> Yes, the kind that carry IP via broadcast. Something like IP over CDMA
> or GSM is much closer to having a wired connection than a broadcast
> connection, since nearby nodes aren't listening to you.
Well, if it's DSS then that's true, but otherwise, the other nodes can
cause interference with you, so if they're doing CSMA-CD, then they are
listening to you, if only to see if the channel is clear to transmit.
>> some wireless networking
>> technologies implement CSMA-CA while others do CSMA-CD; the latter is
>> much more efficient but requires hardware that is capable of listening;
>> in a spread-spectrum implementation (which most 802.11 networks are),
>> CSMA-CA is more common but the DSS implementations mean that there's
>> much less chance of a collision (that's part of the point of that type
>> of implementation).
>
> Sure. But if I have a 10Mbps coax, or a 54Mbps 802.11g, I'm sharing that
> with everyone else on that network. If I can hear everything coming out
> of the router and I have to wait for everyone else to stop transmitting
> before I can, then having multicast not transmit duplicates isn't
> "saving" bandwidth. It's taking up my bandwidth whether I'm listening to
> it or not. If I have a 9Mbps stream coming in, my coax ethernet network
> is going to be slow whether I'm watching video or not. What it *does* do
> is not send it twice when everyone interested has already heard it.
> That's what I was talking about.
Not with multicast IP; again, if you don't subscribe to it, you don't
receive it, at least that's my understanding (http://
www.multicasttech.com/faq/ provides a good explanation).
> However, I strongly suspect that none of this discussion has anything to
> do with whatever Andrew meant when he said IP isn't 1:1 like ISDN is.
Well, quite possibly, unless he was talking about multicast as a reason.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> My point is that ISDN is a point-to-point system, so it doesn't have a
>> concept of network addresses.
>
> WTF? What are you smoking? And can I have some?
>
> http://en.wikipedia.org/wiki/ISDN
So... it's a large page of jargon that I don't really understand. What
specifically am I looking at?
>> Having a global network without addresses doesn't really work.
>
> You *have* heard of phone numbers, haven't you?
Relevance?
>> And that's kind of my point: All the other network systems were
>> designed for networks that are "small", where it's feasible to keep
>> track of all the addresses by hand. None of them really supported
>> having several networks connected together, managed independently.
>
> So, when you make a phone call to someone in the USA, you think there's
> one group of people managing the undersea cable, the wire going into
> your building, and the cell phone towers talking to the cell phone in
> the USA?
All of the other *computer* network systems were designed for small
networks. Sheesh...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> I was simply pointing out that multicast (in particular) isn't
> necessarily point-to-point from an IP standpoint.
Sure. And it's not point-to-point from an ISDN or even POTS perspective
either. Dialing into a conference bridge is the equivalent of putting the
destination address as the multicast address in IP. It's lower-layer
technology that actually does the multicasting, not IP itself.
>>>> You need to duplicate the packets at least once per physical wire.
>>>> Same as any network. IP doesn't force you to duplicate anything less.
>>> True.
>> That's my point. IP is still point-to-point, by necessity, when you
>> don't have a broadcast network.
>
> This is where I think you're talking at the physical or network layer,
> not the transport layer.
The transport layer isn't involved in multicast in IP, per se. Multicast
transport layer is just UDP. The messages maintaining the spanning three
modify things in the network layer.
> and the network hardware understands which ports
> to send the multicast data to,
Then it's not broadcast, and the switch is duplicating the data once for
each subscriber. That's what I'm saying. *If* there's any bandwidth savings
(i.e., more than one NIC reads the same packet), it's because every NIC in
the broadcast area is reading the same packet and some of them are throwing
it away.
>> The ISDN router (known
>> as the conference bridge) is doing the duplication, just like in IP.
>
> Depends on whether you're talking unicast to *each* destination node or
> multicast IP. Therein lies the difference (and the bandwidth savings).
> In a multicast scenario, at the transport layer, the switch isn't
> "duplicating" the packet, it's forwarding it (which may be a semantic
> debate).
It's duplicating it for each outward link the packet goes over. If you have
a router with someone upstream sending a multicast session and three routers
downstream receiving it, how much bandwidth, total, is that taking up?
>>> the switches also typically have logic so they don't have to fill their
>>> buffers with multiple copies of the same data (for those that have a
>>> buffer).
>> True, but now we're talking about something far below the level of IP.
>
> Not in a Layer3 switch we're not. ;-)
I'm pretty sure IP says nothing about how you implement copying a packet
from one NIC to another. :-)
> Yes, physical layer (or network layer), not transport layer. It feels
> like you're conflating the two.
No. I'm pointing out that talking about the bandwidth savings, or "point to
point" ness of IP implicitly is talking about the network and physical
layers. Multicast *is* point to point, *unless* you're on a physical
broadcast network. Multicast is point-to-point between any two elements of
the network where there's a non-broadcast cable between them.
>> The only place that multicast saves bandwidth is on a unicast network
>> (like between routers) where nobody downstream of the receiver wants to
>> receive the data. If you have a separate wire to each PC with bandwidth
>> dedicated to that PC, multicast is 1:1 on any given segment of the
>> network.
>
> The destination "1" is a single multicast address that the specific
> targets subscribe to - that's what makes it not 1:1, but 1:many.
Yes. And 858-102-1137 is a single multicast address that hosts a conference
bridge. Is that not 1:many, if many phones call into that address?
> There again, though, mixing up physical/network layer with transport
> layer.
Only because I'm trying to understand in what possible sense IP is 1:many
and ISDN isn't. Sure, if a conference bridge is 1:many then so is an IP
multicast. But I don't think you can say an IP multicast is 1:many and an
ISDN conference bridge is 1:1, because it's doing the identical thing in the
identical way.
>> Yes, the kind that carry IP via broadcast. Something like IP over CDMA
>> or GSM is much closer to having a wired connection than a broadcast
>> connection, since nearby nodes aren't listening to you.
>
> Well, if it's DSS then that's true, but otherwise, the other nodes can
> cause interference with you, so if they're doing CSMA-CD, then they are
> listening to you, if only to see if the channel is clear to transmit.
I said CDMA, not CSMA. I'm not sure what DSS is here, but in CDMA everyone
talks at the same time, and in GSM (afaik) nobody talks at the same time, so
there's no interference (of the type we're talking about) in either one.
> Not with multicast IP; again, if you don't subscribe to it, you don't
> receive it, at least that's my understanding (http://
> www.multicasttech.com/faq/ provides a good explanation).
If you're on a broadcast network, you have no choice but to receive it. If
you're on a network where each connection is 1:1, then it's the same as an
ISDN conference bridge.
>> However, I strongly suspect that none of this discussion has anything to
>> do with whatever Andrew meant when he said IP isn't 1:1 like ISDN is.
>
> Well, quite possibly, unless he was talking about multicast as a reason.
I don't think so...
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> What do you mean by "2-way broadcast"?
Well, FM radio would be a one-way broadcast. Coax ethernet would be a
two-way broadcast.
> Yes, but from a standpoint of multicast, there again, you get some
> savings (and increased scalability). I imagine (but don't know for sure)
> that cable uses some sort of multicast scheme
Well, look, there really isn't something that's a multicast physical layer.
Either the bandwidth is scaled per user, or it isn't. If we're all talking
at the same frequency on a coax cable (say like old ethernet) and I'm
transmiting, it's a broadcast, regardless of the destination address.
AFAIK, cable systems run fiber to a box in each neighborhood, and then have
a tree of cables coming out from there, all carrying the same signal.
> all people who are watching channel 657 are likely part of a
> multicast group of some sort,
Sure. And all people watching channel 657 are also receiving channel 652.
They're just not tuning it. Just like FM radio. (And I was talking about IP
over cable, actually, not TV per se. :-)
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>>> My point is that ISDN is a point-to-point system, so it doesn't have
>>> a concept of network addresses.
>>
>> WTF? What are you smoking? And can I have some?
>>
>> http://en.wikipedia.org/wiki/ISDN
>
> So... it's a large page of jargon that I don't really understand. What
> specifically am I looking at?
The part that describes ISDN as a global network?
>>> Having a global network without addresses doesn't really work.
>> You *have* heard of phone numbers, haven't you?
> Relevance?
> Having a global network without addresses doesn't really work.
That's the relevance. Do you even *know* what ISDN is? Do you understand
that it's a global network? Do you understand how everyone *except* IP
addresses global networks, specifically because of the sorts of problems you
see with IPv4 address spaces, NATs, routing table overflows, etc etc etc?
>>> And that's kind of my point: All the other network systems were
>>> designed for networks that are "small", where it's feasible to keep
>>> track of all the addresses by hand. None of them really supported
>>> having several networks connected together, managed independently.
>>
>> So, when you make a phone call to someone in the USA, you think
>> there's one group of people managing the undersea cable, the wire
>> going into your building, and the cell phone towers talking to the
>> cell phone in the USA?
>
> All of the other *computer* network systems were designed for small
> networks. Sheesh...
Uh, no. Really, not. X.25. ATM. ISDN. SONET. They're all world-wide
networks-of-networks, just like IP. Indeed, IP runs over top of all these
networks once you get outside your own building. (Granted, X.25 is probably
not much used any more, but it was basically what IP wound up replacing, and
again was the substrate carrier for a lot of IP data before SONET got cheap
enough to dedicate a fiber to something as trickling slow as IP traffic.)
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
