dave@uunet.uu.net (Dave Levenson) (08/22/89)
In article <telecom-v09i0314m02@vector.dallas.tx.us>, munnari!batserver.cs.uq. oz.au!anthony@uunet.uu.net (Anthony Lee) writes: ...description of deadlock resulting from two parties auto-retrying each other... > My question is why is it not possible to have the exchange watch for > such a situation and cancel either the "retry on busy" or "return call > if busy". Is it possible to view the above problem as a deadlock > situation ? It is possible if 'the exchange' serves both parties. But consider that one party may be in New York and the other in Los Angeles. What if there are three parties involved (A trying to reach B who is trying to reach C who is trying A) in three different cities? A similar deadlock may occur with call-forwarding. If two subscribers happen to simultaneously forward to each other, and someone else happens to call either of them, it could create a loop that eventually occupies all of the trunks available between the two exchanges involved. But this doesn't really happen. Here in NJ, if I have call-forwarding, and a call comes in and gets forwarded, no other calls get forwarded until the original call disconnects. Subsequent calls receive a busy signal, just as they would if my calls were not forwarded, and I had answered the origianl call myself. This makes the potential loop situation harmless. -- Dave Levenson Voice: (201) 647 0900 Westmark, Inc. Internet: dave@westmark.uu.net Warren, NJ, USA UUCP: {uunet | rutgers | att}!westmark!dave [The Man in the Mooney] AT&T Mail: !westmark!dave
deej@bellcore.bellcore.com (David Lewis) (08/25/89)
In article <telecom-v09i0314m02@vector.dallas.tx.us>, munnari!batserver.cs.uq. oz.au!anthony (Anthony Lee) writes: >In the proceedings to the 7th International Conference on Software Engineering >for Telecommunications Switching Systems, there is an article by T.F. Bowen >et al from Bellcore. >The article was called "The Feature Interaction Problem in Telecommunications >Systems" The following is a paragraph from the article: [text deleted] >> To make this idea concrete, suppose that customer >>A has automatic "retry on busy", which continues calling a busy line until >>it is free, and customer B has automatic "return call if busy", which >>remembers a call that arrives when the line is busy and returns it as soon >>as the line is free. If A calls B, an infinite cycle of calls could be >>initiated, in which B tries to return A's call but A is retrying B, who >>remains busy trying to call A. > > ..... > >My question is why is it not possible to have the exchange watch for >such a situation and cancel either the "retry on busy" or "return call >if busy". Is it possible to view the above problem as a deadlock >situation ? Part of the problem is that you don't have just *one* situation to watch out for. True, you could have your switches or your service logic (I'm using some perhaps unfamiliar terminology here; sorry -- consider it a peek at Bellcore documents...) (of course, they're not *proprietary* documents, so I won't get fired...) watch for a certain situation. But in an environment where you have a potentially large number of services being introduced fairly rapidly (where "rapid" is in comparison to today's pace -- e.g. two years or less to introduce a new service), you've got an exponentially growing set of pairwise interactions; if you also factor in the multiple states in which any two services can interact... determining the proper pairwise interactions for each new service can become a Very Big Deal. (Which, to my understanding, is the way that it's done in developing a new switch generic today -- and guess how many staff-years it takes to create a new generic? Lots.) -- David G Lewis ...!bellcore!nvuxr!deej "If this is paradise, I wish I had a lawnmower."