jbn@wdl1.UUCP (01/23/86)
One annoying problem with Ethernet-type systems is that you send
blind; there's no link-level indication that nobody is listening to you.
This causes some problems in adaptive routing that I won't go into here.
This ought not to be a problem with token rings, since the receiver
usually takes the message off the ring and replaces it with the token.
(You could cheap out and let the sender take it off the ring, but it
halves the ring bandwidth if you do, of course.)
If the sender sees a message with its own source address go by, it has
to remove it to prevent it going around forever, and this indicates a
failure to deliver the message. (You could really cheap out and let the
ring time out and regenerate the token whenever this happens, but then
sending to a dead node will tie down the ring for some time.)
Which token rings actually provide indication of non-delivery to the
sender? I've been told that the Cambridge Ring does and Proteon does not.
Who has hard information on this?
John Naglejohnl@ima.UUCP (01/24/86)
/* Written 2:14 pm Jan 22, 1986 by jbn@wdl1 in ima:net.lan */ > Which token rings actually provide indication of non-delivery to the > sender? I've been told that the Cambridge Ring does and Proteon does not. I don't know about those two, but can shed some light on the IBM Token Ring. This comes from an article on a "hypothetical" token ring published in the IBM Journal of R&D in September of 1983. In the IBM scheme, the sender gets the token and puts out a packet as you would expect. The receiver passes the packet through but sets some bits, and the sender removes the packet and regenerates a free token. The receiver can set two bits: an "address recognized" bit meaning that it recognized that the packet was addressed to it, and a "frame copied" bit meaning that it actually read in the frame. Normally the receiver would set both bits, but might set only the first if it had no buffer space to receive the packet. There is also a complicated priority reservation scheme that allows nodes to grab the token when they have something really important to say. This scheme does lower the bandwidth compared to one where the receiver passes on a free token, but has much better error properties. If the receiver passed on a short free token as soon as it got the header of a long data packet, you'd have confusing situations where the sender got the free token back long before it had finished sending a packet. Besides, if the receiver sends the token before it's received the whole data packet, it'll have no way to report if the packet isn't received right. So it might as well pass the data packet back to the sender, which allows broadcast packets as a free side benefit. The time difference between that and passing a delayed free token is at worst one trip around the ring which should be short compared to a typical packet time. John Levine, ima!johnl PS: Personally, I like Ethernet.
mar@mit-eddie.UUCP (Mark Rosenstein) (01/31/86)
In article <952@wdl1.UUCP> jbn@wdl1.UUCP writes: > > Which token rings actually provide indication of non-delivery to the >sender? I've been told that the Cambridge Ring does and Proteon does not. >Who has hard information on this? > > John Nagle The Proteon proNET ring does have hardware acknowlegement. The sender removes the packet from the ring, not the receiver. However, the receiver does reset a bit at the end of the packet as it goes by if it was received successfully. In this way broadcast can work the same as sending regular packets. -Mark Rosenstein work: mar@proteon.arpa (617) 655-3340 other: mar@borax.lcs.mit.edu (617) 497-4863 ...ihnp4!mit-eddie!mar Disclaimer: I do work for Proteon, but as a programmer not a hardware person. I think I've just told the truth, although this is not an official statement of Proteon, Inc.
taylor@glasgow.UUCP (02/04/86)
In article <952@wdl1.UUCP> jbn@wdl1.UUCP writes: > Which token rings actually provide indication of non-delivery to the >sender? I've been told that the Cambridge Ring does and Proteon does not. Actually, Cambridge Ring is a *slot* ring. However, in a slot ring, if you see the mini-packet you sent not marked as recieved ( in fact there are 4 different statuses/stati it could have - accepted, rejected, no-one there and another ... ), that is, unmodified except for the 'monitor-passed' flag, you know your addressee is not on the ring. There's no problem about loss of token, because there's no token ... -Jem- -- JANET: taylor%glasgow.uucp@uk.ac.ed.cstvax -o Jemima UUCP: { uk }!cstvax!glasgow.uucp!taylor (==). Puddleduck