A small friendly city, uncluttered minds around, a nice ambiance, two young hearts(call it a server and a client) and a sense of belonging. All just perfect to form the firm layers at the bottom to give a strong end to end connection. A continuous stream of feelings were supposed to pass uninterrupted between the two hearts with both connected forever. All that was needed to set it up and running was a "connect" at one end and an "accept" at the other end.Subsequently there was "send"ing and "recv"ing of messages. Many acknowledgments and requests were required to make it work in harmony. No errors or congestion were expected on the way. All this formed an ideal protocol for a smooth exchange of thoughts, a bliss that was long yearned for!
But this is just an ideal scenario! There are always exceptions!Rather unhandled exceptions. Many factors like congestion of thoughts, a loosening foundation and a drop in the service rate started affecting the quality of service. So, in the process, a delay caused losses of acknowledgments and eventually no requests appeared on either ends! Thus a "disconnect" was called by our server that was in a hurry, that did not have the required queue space to entertain more requests if they came. The other side, the client, could only receive, and though wanted to send, just could not! Seeing no requests the impatient server called a "timeout". The receiving client now had nothing to call a connection, and timed out without a "disconnect". This was never a synchronous exchange!
Well, that was a perfect recipe for an uncalled disaster. Nothing to be blamed but the design of the protocol!
The consequence was an unordered useless bursts of data.
A horrendous Twisted Connection Protocol!
But this is just an ideal scenario! There are always exceptions!Rather unhandled exceptions. Many factors like congestion of thoughts, a loosening foundation and a drop in the service rate started affecting the quality of service. So, in the process, a delay caused losses of acknowledgments and eventually no requests appeared on either ends! Thus a "disconnect" was called by our server that was in a hurry, that did not have the required queue space to entertain more requests if they came. The other side, the client, could only receive, and though wanted to send, just could not! Seeing no requests the impatient server called a "timeout". The receiving client now had nothing to call a connection, and timed out without a "disconnect". This was never a synchronous exchange!
Well, that was a perfect recipe for an uncalled disaster. Nothing to be blamed but the design of the protocol!
The consequence was an unordered useless bursts of data.
A horrendous Twisted Connection Protocol!
Posts
Hehe, loved your OOBT here; But, given the parametric equation of the "Twisted CP", I felt that there could be other probabilistic discrete events that could be considered as one of the possible reasons for the so-called "uncalled disaster".
For the uninitiated, I feel that the present generation[ Ok,Ok- I know that i am no octogenarian!.But, yeah- I prefer this usage!] use a hybrid media of communication- Its somewhere along the lines of spread spectrum,but, on the other hand it could well be a short distance radio as well!.
Away from the skews of puzzles and esoteric thoughts- Lets get to the "other view". I feel that there are two other coherent cause for this clause.
Firstly, I feel that the "Common control channel problem" is pretty severe. I think that the loss of packets due to congestion could well be undermined by the CCC problem; where the parties believe that they have an established a connection via a deeply "virtual" tableau!-viz- They virtually assume that they virtual connection and start sending the data packets.In this case failure is inevitable, moreso, because of the complexity of this problem being Order of O(virtual-squared!).
Then comes the "hidden terminal problem"-This is another predominant trait of problems where each of the parties actually oversee the existence of a possible means of undeterred communication between them.So,eventually they end up dead-locked instead of a very possible wed-lock.
Arent these a plausible cause?
Well i admire your cognizance here! But the TCP works on pure handshaking mechanism. So assumptions has no way of affecting a connection. Its there or its just not! Dont you think the problem is solved?