Abstract:
To manage a connection in a connection-oriented in-order delivery environment, a connection is established between a client and a server in an in-order delivery environment where the message exchange is based on a reliable network and, an unreliable network, also taking traffic classes for real-time operation into account. In comparison to present examples message overhead sequence numbers can be saved and the number of messages can be streamlined and reduced. Further, some error cases are also discussed taking also the bandwidth allocation by forwarding of messages across routers into account.

Description:
TECHNICAL FIELD 
       [0001]    The present disclosure relates to a method and system for communication among components in a multi-component system interconnected by a network featuring in-order delivery of communicable items. 
       BACKGROUND 
       [0002]    In high integrated systems that are currently developed high bandwidth communication capacity is a prerequisite as a performance requirement. Furthermore the system developer pursuing a second source principle must be able to select the components of his design from any manufacturer and at the same time requires them to interoperate flawlessly. This leads to the formation of standardization organizations founded by a plurality of manufacturers active in the field, that define standards for components and intercommunication thereof. One such a standardization organization is the Mobile Industry Processor Interface Alliance (MIPI®). Currently this organization groups around  150  manufacturers working on the details of mobile systems intercommunication. Some information is available at mipi-dot-org on the World Wide Web. 
         [0003]    In order to standardize intercomponent communication the MIPI® alliance has defined UniPro SM  as a serial high-speed link for connecting devices in a mobile system. The UniPro SM  standard is under steady development and currently standard version 1.0 is released. Some information about the features of the various versions of the standard is available on the Internet encyclopedia at wikipedia-dot-org/wiki/Unipro on the World Wide Web. 
         [0004]    By providing an interconnection and communication standard the manufacturers are much more flexible in developing their systems and able to mix and match components well suited for different requirements and provided by different vendors. The UniPro SM  standard or Unified Protocol is directed to chip-to-chip networks that make use of high speed serial links. It is defined to be a general purpose communication protocol that solves the general interconnect problems such as error handling, flow control, routing and arbitration. 
         [0005]    Currently UniPro SM  offers connection-oriented communication which requires a connection to be set up, while at the same time allocating a state and other resources such as buffers. Usually connections implement a credit end-to-end flow control to prevent the buffers involved in communication from overflowing. This, in combination with the use of a reliable network guaranteeing no data loss or corruption secures a reliable communication service to the user. 
         [0006]    For future developments, UniPro versions are foreseeable that provide a real-time traffic class, having a consequence of limiting the number of layer 2 retransmissions thereby ensuring a time limit for the delivery of a packet by sacrificing a guarantee for the data delivery itself, because limiting the number of layer 2 retransmission creates a very small probability of fragments of data to not being delivered. Higher layers of the UniPro applications will have to take care of the missing fragments, when they receive corresponding reports. Reliable and real-time traffic classes being based on connection-oriented communication require a protocol to initiate maintain and terminate a connection. At present from the transmission control protocol TCP a three-way handshake is known. Details are published in the transmission control protocol, DARPA Internet program, protocol specification by Information Sciences Institute, University of Southern California, IETF Request For Comments #793, September 1981. However, TCP is much different from the Unified Protocol as it has to cope with a high unreliability which is intrinsic to the network and therefore needs to take precautions in the protocol to cope with such unreliabilities. TCP also assumes no order in the data delivery, since e.g., packets may take different routes in the network. Therefore, TCP uses very large sequence numbers as well as a maximum packet lifetime to ensure the management of connections. UniPro however is mostly operated in small networks of typically up to 10 nodes and provides in-order communication. Therefore, it is possible to use less overhead than with normal protocols and achieve simplicity without sacrificing functionality. 
         [0007]    Also known in the art is the ATM connection setup which is disclosed in the ITU-T Q.2931 at B-ISDN application protocols for access signaling, as disclosed in ITU-T recommendation Q.2931, February 1995. The related connection setup uses a mechanism which is similar to the one used in TCP, using sequence numbers which are called reference in ATM. However ATM also is based on large sequence numbers which creates a message overhead and thus takes bandwidth from the communication channel. 
       SUMMARY 
       [0008]    It is an object of the present disclosure to provide an alternative method and system for managing a connection in a connection-oriented in-order delivery environment which allows an adequate allocation of resources and the establishing and terminating of connections with a minimum of message overhead. 
         [0009]    This problem is solved by a method for managing a connection in a connection-oriented in-order delivery environment and a system for managing a connection in a connection-oriented in-order delivery environment. Advantageous further embodiments are also disclosed 
         [0010]    Expediently the method according to the present disclosure provides a minimum number of messages and protects a dropping of the first message by the server. In this manner although using a reliable network the method protects against a busy server that has no resources available for dealing with the connection, due to e.g. processing another connection. 
         [0011]    Expediently according to a further embodiment of a method according to the present disclosure in case a first predefined time period expired another first type of message is sent to the server to guarantee establishing of the connection within the shortest possible time and at the same time dealing with a dropping of the first type of message by the server in the first transmission while allowing the server a sufficient amount of processing time. 
         [0012]    Advantageously according to a further embodiment of a method according to the present disclosure receiving a second type of message leads to the client being connected while sending a fourth type of message allows the method to deal with unreliable networks or with real-time traffic classes to communicate to the server that the confirmation message has been received. 
         [0013]    Beneficially the confirmation message according to a further embodiment of the method of the present disclosure in the form of the second type of message from the server to the client is safeguarded by a first server tinier measuring a second predefined time period to protect the connection establishment from a loss of this message, while receiving a fourth type of message as a confirmation from the client that the confirmation message from the server has been received stops the first server timer. In this manner a minimum number of messages guarantee the secure establishment of a connection. 
         [0014]    Expediently according to a further embodiment of the method according to the present disclosure the server generates a fifth type of message and sends it to the client in case it is not able to establish a connection due to unavailable resources, because of dealing with another connection, or high processing load of another application. This message when received at the client allows it advantageously to close the connection and thus provides a method to put the client in a defined state, while the server is unavailable. 
         [0015]    Advantageously according to a further embodiment of a method according to the present disclosure a second client tinier measuring a third predefined time period is started, when a third type of message is sent, in order to secure a defined termination of the connection and to take appropriate measures, once no response to the third type of message is received in the third predefined time period. 
         [0016]    Beneficially according to a further embodiment of a method according to the present disclosure when the server receives the third type of message it sends a sixth type of message to the client in order to confirm the reception of the third type of message thus a close structured handling and management of the connection establishing and termination is secured. 
         [0017]    Expediently according to a further embodiment of a method according to the present disclosure the sending of the sixth type of message starts a second server timer to safeguard the secure communication with the client in this case, once a non-reliable network is used for transmitting the message, respectively a network with a traffic class for real-time communication. 
         [0018]    Beneficially according to a further embodiment of a method of the present disclosure, the second client timer is stopped, once the client receives the sixth type of message and thus knows, that the server is closing the connection while at the same time a seventh type of message is sent to the server in order to confirm the reception of the sixth type of message and to ensure a defined status as well at the server as at the client. 
         [0019]    Advantageously according to a further embodiment of a method of the present disclosure any message exchanged between the client and the server is capable of passing through a router, to enhance the flexibility in the communication between the client and the server while at the same time allowing to define the requested bandwidth for the connection depending on the application, respectively traffic class. At the same time the router provides for only forwarding the message received, once the required bandwidth is available. 
         [0020]    Expediently according to a further embodiment of the method according to the present disclosure, once the router is available to provide the requested bandwidth, it protects against further bandwidth allocation until it receives a confirmation message from the server which was addressed by the client, while rejecting communication from other servers and clients. In this manner, the bandwidth allocation is secured from access by other potential communication partners. 
         [0021]    Advantageously a further embodiment of the method according to the present disclosure allows the client to be addressed by an application client initiating the messages at the client, while the server communicates with an application server and thus establishing communication between an application server and an application client by means of the client and the server exchanging messages for communication establishment in order to provide for a data exchange via the established connection between the application client and the application server. 
         [0022]    Advantageously a system according to the present disclosure provides a server and a client as well as a network with in-order delivery in a minimum configuration to execute the actions of the method according to the present disclosure. 
         [0023]    Advantageously a further embodiment of the system according to the present disclosure provides a router to extend the flexibility and the communication distance between the client and the server while making use of embodiments of the method according to the present disclosure. 
         [0024]    Advantageously according to a further embodiment of the system of the present disclosure acknowledgement messages that are not used at the same time during communication are saved as only one message in one format and in the communication context provide for the right activity at the server respectively client. As well the server timers and the client timers that are not running at the same time may also only be implemented as respectively one server timer and one client timer that are activated when required and then implement the first respectively second respectively server respectively client timer in the message exchange according to the method of the present disclosure and its embodiments. 
         [0025]    Other features and advantages will be understood upon reading and understanding the detailed description of exemplary embodiments, found herein below, in conjunction with reference to the drawings, a brief description of which is provided below. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
         [0026]    Below examples of embodiments of the present disclosure will further be described based on examples depicted in drawings. The drawings described are only schematic and are non-limiting. In the drawings, the size of some of the elements may be exaggerated and not drawn to scale for illustrative purposes. The same reference indicators will be used throughout the drawings and the following detailed description to refer to the same or like parts. 
           [0027]      FIG. 1  shows a typical message exchange taking place in a reliable network, 
           [0028]      FIG. 2  shows a state machine depicting examples of states and state transitions in a reliable network, 
           [0029]      FIG. 3  shows examples of states and state transitions of a server in a reliable network, 
           [0030]      FIG. 4  shows a message flow as an example in an unreliable network, 
           [0031]      FIG. 5  shows states and state transitions as an example of the client in an unreliable network, 
           [0032]      FIG. 6  shows an example of states and state transitions of a server in an unreliable network, 
           [0033]      FIG. 7  shows an example of a message flow between server client and router including bandwidth allocation, 
           [0034]      FIG. 8  shows an example of a message flow between a client and a server in an unreliable network while messages pass through a router, 
           [0035]      FIG. 9  depicts states and state transitions as an example of a client in an unreliable network including a router in the message flow, 
           [0036]      FIG. 10  explains states and state transitions of a server as an example in an unreliable network containing a router in the message flow, 
           [0037]      FIG. 11  depicts and states and state transitions as an example of a router included in the message flow between a client and a server in an unreliable network, 
           [0038]      FIG. 12  shows an example of a message exchange between a client and a server in a reliable network when the server is busy, 
           [0039]      FIG. 13  shows an example of a message exchange between a client and the server when the first type of message gets lost, 
           [0040]      FIG. 14  gives an example of a message exchange between a client and server where the second type of message is lost, 
           [0041]      FIG. 15  depicts an example of a message flow between a client and the server, where the server application has crashed, 
           [0042]      FIG. 16  gives an example of a message flow between a client and the server, in an unreliable network where the server is busy, 
           [0043]      FIG. 17  depicts an example of a message exchange between a client and a server, where a protocol error occurs, 
           [0044]      FIG. 18  depicts an example of a first error taking place in an unreliable network including a router, 
           [0045]      FIG. 19  depicts a second error as an example taking place in the communication between a client and a server including a router on the path, 
           [0046]      FIG. 20  shows a third example of a communication error occurring between a client and a server having a router in between, and 
           [0047]      FIG. 21  gives a fourth example of a communication error that occurs in the communication between a client and a server, the message exchange passing through a router. 
       
    
    
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
       [0048]    There follows a more detailed description of the exemplary embodiments. Those skilled in the art will realize that the following detailed description is illustrative only and is not intended to be in any way limiting. Other embodiments of the present disclosure will readily suggest themselves to such skilled persons having the benefit of this description. Reference will now be made in detail to embodiments of the present disclosure as illustrated in the accompanying drawings. Thus the principles of the present disclosure will be described with respect to particular embodiments and with reference to certain drawings but the invention is not limited thereto but only by the claims. 
         [0049]    Throughout the description of the drawings which relate to state machines as in  FIGS. 2 ,  3 ,  5 ,  6 ,  9   10  and  11  for the sake of efficiency the following syntax is used for explaining a trigger of a state transition and an event generated by it: 
         [0050]    A format like &lt;trigger&gt;/&lt;action&gt; is used for the notation in the state machines. Here &lt;trigger&gt; serves as a placeholder of an input trigger which serves as a trigger which led to the corresponding transaction. Further &lt;action&gt; serves as a placeholder for a set of the resulting events that are associated with the transaction. 
         [0051]    Where the term “comprising” is used in the present description and claims, it does not exclude other elements or steps. Furthermore, the terms first, second, third and the like in the description and in the claims, are used for distinguishing between similar elements and not necessarily for describing a sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances and that the embodiments described herein are capable of operation in other sequences than described or illustrated herein. 
         [0052]      FIG. 1  shows an example of a message flow for connection management according to an embodiment of the present disclosure in a reliable network. Throughout the discussion of the drawings the same reference signs will be used for the same entities in all of the drawings and a redundant description thereof will be omitted for the sake of efficiency. 
         [0053]    As  FIG. 1  exemplifies an application client  1000  communicates with a client  1100 , a server  1200  and an application server  1300  using a reliable network. The network may be a simple link, or may contain one or more routers. However, for simplicity, no router is depicted in  FIG. 1 . The application client  1000  sends a message  1010  “T_OPEN.req” to the client  1100  which at that time is in a state  1130  of “C_Closed” to initiate the establishment of a connection. At the client  1100  a timer is started once a first type of message  1140  “T_SYN” is sent to the server  1200  which at that time is in an “S_Listen” state. The server generates a message “T_OPEN.ind”  1310  to the application server  1300  which in case of being able to handle the data replies with a message  1320  to the server “T_OPEN.rsp”. The server  1200  measures the time interval between messages  1310  and  1320  with a first server timer while being in a state  1220  “S_WaitRsp”. Receiving the message  1320  the first server timer is stopped, which measures a second predefined time period and a second type of message  1150  “T_SYN_Ack” is sent to the client  1100  stopping the first client timer which had been started when the message  1140  was generated being in a state  1120  “C_WaitAck” and generating a message  1020  “T_OPEN.cnf”. The server  1200  now being in a state  1230  “S_Connected” now is connected. Now the application client starts sending a request for transmission of data  1030  “T_DATAreq” which is confirmed by the client  1100  with a confirmation message  1040  “T_DATAcnfL”. The server  1200  receives the transmitted data  1160  “T_DATA” and sends to the application server the data from the application client  1330  “T_DATAind” which responds with a message  1340  “T_DATArspL” leaving the server in an “S_Connected” state and the client in an “T_Connected” state  1110 . 
         [0054]    Data may also be requested from the application server by sending a message  1350  “T_DATAreq” to the server  1200  which is forwarded to the client  1100  as a message  1160  “T_DATA” and from there on forwarded to the application client as a message “T_DATAind”  1050  prompting the application client to respond with a message  1060  “T_DATArspL” to the client  1100  which is in a “C_Connected” state  1170 . 
         [0055]    To terminate the connection the application client sends a message  1070  “T_CLOSE.req” confirmed by the client  1100  with a message  1080  “T_CLOSE.cnfL” which generates a message  1170  “T_FIN” to the server  1200  responding to the application  1300  with an indication of the connection close  1370  “T_CLOSE.ind” confirmed by the server  1300  with a message  1380  “T_CLOSE.rspL” transferring the server to a state  1240  “S_Listen”. Alternatively, the connection may be closed by the server  1200  by sending a message  1170  “T_FIN” when this is requested by the application server  1300  with a message  1070  “‘T_CLOSE.req” (confirmed by message  1080  “T_CLOSE.cnfL”) and indicated with a message  1370  “T_CLOSE.ind” (responded with message  1380  “T_CLOSE.rspL”). 
         [0056]    The client remains in a state  1130  “C_Closed”. The timer between messages  1140  and  1150  is required even though a reliable network forms the basis of the communication as the first type of message  1140  may be dropped by the server in case there are no resources available to process the message. The timer run by the server between the messages  1310  and  1320 , measuring the second predefined time period is optionally available to supervise if an application at the application server which is required in the communication has crashed or is not available for another reason. 
         [0057]    Expediently the client  1100  should provide resources for the reception of message  1150  which is prone to arrive after sending the message  1140 . In this manner advantageously at the server  1200  no timer is needed to supervise the proper transmission of the message  1150 . Similarly, the client  1100  and/or server  1200  should provide resources for the reception of message  1170 . In this manner, the sender of the message  1170  needs no timer to protect against the transmission loss of message  1170 . 
         [0058]      FIG. 2  shows a state machine associated to the message flow demonstrated in  FIG. 1  as an example of states and state transitions that can be adopted by the client. 
         [0059]    In order to further explain the notation of the state machines in this description an example referring to  FIG. 2  is given, which is however also applicable in an analogous manner to the other Figures representing state machines. Here in  FIG. 2 , the client transition  2100  from state  1130  to state  1120  is triggered by the reception of T_OPEN.req (mLserver) from the application client  1000 , and also leads to transmitting T_SYN (to:mLserver) to the server  1200  and starting Timer SYN at the client  1100 . With the above notation, this is denoted as  2100 : T_OPEN.req (mLserver)/T_SYN (to:mLserver), start Timer SYN. 
         [0060]    As another example, the trigger event for transition  2200  is the expiration of Timer_SYN, and also leads to transmitting T_SYN (to:mLserver) to the server  1200  and restarting Timer SYN at the client  1100 . This is denoted as  2200 : timeout Timer_SYN/T_SYN (to:mLserver), restart Timer_SYN. 
         [0061]    Being in a state  1130  the client may transfer to a state  1120  “C_WaitSynAck” corresponding to  2100 : T_OPEN.req (my_server)/T_SYN (to:my_server), start Timer_SYN. The client remains in the state  1120  corresponding to  2200 : timeout Timer_SYN/T_SYN (to:my_server), restart Timer_SYN, whereas a transition back to the state  1130  happens according to  2150 : T_SYN_ERR (from:my_server)/T_OPEN.cnf (error), stop Timer_SYN. A transition from the state  1120  to the state  1110  “C_Connected” takes place according to  2300 : T_SYN_ACK (from:my_server)/T_OPEN.cnf (ok), stop Timer_SYN or  2300 : T_DATA (from:my_server)/T_OPEN.cnf (ok), stop Timer_SYN, T_DATA.ind, whereas the client stays in the state  1110  corresponding to  2400 : T_DATA.req/T_DATA (to: my_server), or  2400 : T_DATA (from:my_server)/T_DATA.ind and transits to a state  1130  by  2500 : T_CLOSE.req( )/T_CLOSE.cnf, T_FIN (to:my_server). 
         [0062]      FIG. 3  shows a state machine as an example of states and state transitions a server can adopt in the context of the message flow shown in  FIG. 1 . 
         [0063]    A state “S_WaitCloseRspE”  3220 , a state  3420  “S_Error”, a state  1220  “S_WaitOpenRsp”, a state  1230  “S_Connected” and further states  3320  “S_WaitCloseRsp” and a state  1210  “S_Listen” are shown. 
         [0064]    Transitions from state  1210  to state  1220  occur by  3350 : T_SYN (from:my_client)/T_OPEN.ind (my_client), start Timer_Rsp; from state  1220  to  3420  by  3200 : timeout Timer_Rsp/stop Timer_Rsp, T_SYN_ERR (to:my_client); and from state  1220  to state  1230  corresponding to  3300 : T_OPEN.rsp( )/stop Timer_Rsp, T_SYN_ACK (to:my_client). A state transition from state  3420  to state  3220  occurs according to  3100 : T_OPEN.rsp( )/ T_CLOSE.ind( ). 
         [0065]    Further transitions occur from state  1230  to  3320  corresponding to  3450 : T_FIN (from:my_client) 1T_CLOSE.ind( ); and from state  3320  to state  1210  by  3550 : T_CLOSE.rsp 1T_FIN (to:my_client). State  1210  is initially triggered by the event  3650 : T_L1STEN.req/-. The server stays in state  3420  according to transition,  3150 : T_SYN (from:any_client)/T_SYN_E (to:any_client). The server stays in state  1230  according to transition  3400 : T_DATA.req (data)/T_DATA (to:my_client, data), or  3400 : T_DATA (from:my_client, data) 1T_DATA.ind (data), or  3400 : T_SYN (from:my_client)/T_SYN_ACK (to:my_client) or  3400 : T_SYN (from:other_client) 1T_SYN_ERR (to:other_client). The server stays in state  3320  according to transition  3500 : T_DATA.req (data)/T_DATA (to:my_client, data), or  3500 : T_SYN (from:other_client)/T_SYN_ERR (to:other_client). 
         [0066]    For instance, in the state  3320  the server is still able to send data, but won&#39;t receive any more data from the client. 
         [0067]      FIG. 4  shows an example of a message flow of an embodiment according to the present disclosure which takes place in an unreliable network, respectively a network that restricts the number of layer 2 retransmissions. 
         [0068]    As can be easily identified in comparison with  FIG. 1  most of the messages that are exchanged are the same. Due to that fact, a focus is being placed on the differences in the message flow that separates the messages needed in a reliable network from the messages needed to establish a connection in an unreliable network. 
         [0069]    In case of an unreliable network additional timers and messages are preferably provided to compensate for the unreliability and to secure the establishment of a connection. In this case the client  1100  generates a fourth type of message  4150  “T_ACK_ACK”. This fourth type of message is provided in case of an unreliable network conducting the message flow to supervise the proper transmission of the second type of message  1150 . The proper and timely transmission of the fourth type of message is evaluated by a second server timer running at the server  1200  while being in a state  7510  “S_WaitSynAck”. In this case the client transits in a state  4110  “C_Connected” after having transmitted the fourth type of message  4150 . 
         [0070]    Another particularity of this message flow is located in the termination of the connection where the proper response to the third type of message  1170  during termination of the connection is supervised by a timer while the client itself is in a state  4110  “C_WaitFinAck”. The second client timer is stopped, once the message  4170  “T_FIN_ACK” is received from the server  1200  acknowledging the termination of the connection. 
         [0071]    In case of basing the message transfer on an unreliable network the links may discard packets. This may be the case for a traffic class which has a bounded number of retransmissions for instance 0 or 1 to bound the message delivery time. Due to this procedure occasionally fragments or an entire message will be lost or message will be delivered with known errors in their payload. Thus also connection management messages may be discarded without processing. In particular here the second type of message  1150  from the server should be preferably protected, because in an error case due to a loss the server may remain in an “S_Connected” state  1230  after being at first busy and then becoming available with a second type of message  1150 . 
         [0072]    This may lead to a case where the server assumes being connected and starts sending data to a client which isn&#39;t connected and thus not prepared to receive data. 
         [0073]      FIG. 5  shows a state machine depicting examples of states and transitions in between states for a client associated to the message flow shown in  FIG. 4 . 
         [0074]    In this case the situation present in an unreliable network, shown in this embodiment shows as a difference compared to the client in a reliable network which was depicted in  FIG. 2  the addition of the state  4110  in the context of terminating the connection “C_WaitFinAck”. Further states are  1110  “C_Connected”,  1130  “C_Closed” and  5120  “C_WaitSynAck”. 
         [0075]    A transition from state  1130  to state  5120  corresponds to  5150 : T_OPEN.req (my_server)/T_SYN (to:my_server), start Timer_SYN. A transition from a state  5120  to a state  1110  occurs corresponding to  5250 : T_SYN_ACK (from:my_server)/T_ACK_ACK (to:my_server), T_OPEN.cnf (ok), stop Timer_SYN. A transition from the state  1110  to the state  4110  corresponds to transition  5450 : T_CLOSE.req( )/T_FIN (to:my_srever), start Timer_FIN. It is also possible to arrive from a state  5120  at state  4110  according to  5300 : T_SYN_ERR (from:my_server)/T_FIN (to:my_server), start Timer_FIN, and from state  4110  to state  1130  according to transition  5550 : T_FIN_ACK (from:my_server)/T_CLOSE.cnf( ), stop Timer_FIN. In case of transition  5100 : T_FIN_ACK (from:any_server)/-; transition  5200 : T_FIN_ACK (from:any_server)/-; transition  5200 : timeout Timer_SYN/T_SYN (to:my_server), restart Timer_SYN; transition  5400 : T_DATA.req/T_DATA (to:my_server); transition  5400 : T_DATA (from:my_server)/T_DATA.ind; transition  5400 : T_FIN_ACK (from:other_server)/-; transition  5400 : T_SYN_ACK (from:my_server) 1T_ACK_ACK (to:my_server); transition  5500 : T_SYN_ACK (from:my_server)/T_FIN (to:my-server); transition  5500 : T_SYN_ERR (from:my_server)/T_FIN (to:my_server); transition  5500 : T_FIN_ACK (from:other_server)/-; and transition  5500 : timeout Timer_FIN/T_FIN (to:my_server), restart Timer_FIN, the respective states  1130 ,  5120 , 1110  and  4110  are maintained, respectively. 
         [0076]    If in case of the state  5120  a second type of message  1150  respectively an error message is received they are responded with a third type of message  1170 . In this case the second client timer is restarted. Both client timers in this case e.g. are mutually exclusive and therefore may be implemented as a single timer taking the function of both. 
         [0077]      FIG. 6  shows a state machine depicting examples of states and transitions between states of a server  1200  in a communication situation of an unreliable network as shown in  FIG. 4 . 
         [0078]    Here in comparison to the situation of a server making use of a reliable network it also receives the fourth type of message  4150  as an acknowledgement from the client  1100 . As well it issues a sixth type of message  4170 . 
         [0079]    In the diagram of  FIG. 6  a state  6520  “S_WaitCloseRspE” is shown accompanied by a state  6550  “S_Error” and a state  1240  “S_Listen” as well as a state  6220  “S_WaitOpenRsp” and a state  6620  “S_WaitSynAck”. Also shown are the state  1230  “S_Connected” and the state  6420  “S_WaitCloseRsp”. 
         [0080]    The state  1240  is initiated by  6800 : T_L1STEN.req/- and is maintained in case of  6750 : T_FIN (from:any_client)/T_FIN_ACK (to:any_client). A transition from there according to  6850 : T_SYN (from:my_client) 1T_OPEN.ind (my_client), start Timer_Rsp; to the state  6220  takes place, which is maintained in case of  6300 : T_FIN (from:other_client)/T_FIN_ACK (to:other_client). From there the state  6550  may be reached in case of  6250 : timeout Timer_Rsp/stop Timer_Rsp, T_SYN_E (to:my_client); and is maintained corresponding to  6150 : T_SYN (from:any_client)/T_SYN_E (to:any_client), or  6150 : T_FIN (from:any_client)/T_FIN_ACK (to:any_client). From this state  6550  the state  6520  can be reached by  6200 : T_OPEN.rsp( )/T_CLOSE.ind( ); which is maintained according to  6100 : T_SYN (from:any_client)/T_SYN_ERR (to:any_client), or  6100 : T_FIN (from:any_client)/T_FIN_ACK (to:any_client). 
         [0081]    Another transition from the state  6220  to the state  6620  takes place corresponding to  6350 : T_OPEN.rsp( )/stop Timer_Rsp, T_SYN_ACK (to:my_client), start Timer_ACK. The respective state is maintained corresponding to transition  6400 : T_SYN (from:my_client)/T_SYN_ACK (to:my_client), transition  6400 : T_SYN (from:other_client)/T_SYN_ERR (to:other_client), transition  6400 : T_FIN (from:other_client)/T_FIN_ACK (to:other_client), or transition  6400 : timeout Timer_ACK/T_SYN_ACK (to:my_client), restart Timer_ACK; and from there according to  6450 : T_ACK_ACK (from:my_client)/stop Timer_ACK, or  6450 : T_DATA (from:my_client, data)/stop Timer_ACK, T_DATA.ind (data); the state  1230  is reached, which is maintained by transaction  6550 : T_DATA.req (data)/T_DATA (to:my_client, data), transaction  6550 : T_DATA (from:my_client, data)/T_DATA.ind (data), transaction  6550 : T_SYN_ACK (from:other_client)/-, transaction  6550 : T_SYN (from:other_client)/T_SYN_ERR (to:other_client), or transaction  6550 : T_FIN (from:other_client)/T_FIN_ACK (to:otherclient). From there the state  6420  is adopted corresponding to  6600 : T_FIN (from:my_client)/T_CLOSE.ind( ); and will be maintained according to transition  6650 : T_DATA.req (data)/T_DATA (to:my_client, data), transition  6650 : T_FIN (from:my_client)/-, transition  6650 : T_SYN (from:other_client)/T_SYN_ERR (to:other_client), transition  6650 : T_FIN (from:other_client)/T_FIN_ACK (to:other_client). This state then may be left by a transition to the initial state  1240  corresponding to  6700 : T_CLOSE.rsp/T_FIN_ACK (to:my_client) occurring. 
         [0082]    Another transition from the state  6220  to the state  1240  takes place corresponding to  6500 : T_FIN (from:my_client)/T_FIN_ACK (to:my_client). 
         [0083]    The term “my_client” identifies the application client whereas the term “my_server” identifies the application server in the drawings. 
         [0084]      FIG. 7  shows an example of an embodiment of a method according to the present disclosure where the messages exchanged between client and server are forwarded by a router. This method advantageously applies bandwidth reservation for the connection and verification of available bandwidth before establishment of a connection. The main difference between this message chart and the chart showing the message flow depicting the connection management in a reliable network in  FIG. 4  is that, if a router is present between the client  1100  and the server  1200 , the router forwards messages that in  FIG. 4  are exchanged between the client  1100  and the server  1200  and advantageously performs a bandwidth allocation respectively a bandwidth evaluation checking the availability of the bandwidth requested for the respective connection. In particular here the router  7500  is new and taking its respective states  7510  “R_Ready” as well as  7530  “R_Busy”. Furthermore the message format of the first type of message in comparison to the one explained in the previous drawings contains a bandwidth request and therefore is identified by reference numeral  7140  “T_SYN(bw)”. Also the message format of the third type of message now preferably contains a bandwidth request and therefore is identified by different reference numeral  7170  “T_FIN(bw)”. The router  7500  between the client  1000  and the server  1100  here uses for instance a bandwidth parameter or a plurality of bandwidth parameters to evaluate if the requested bandwidth fits the link capacity given that some of the link bandwidth may already be reserved for other connections if the bandwidth reservation succeeds, the router forwards the first type of message otherwise for instance it generates an error communicated either to the client  1000  or the server  1100 . Furthermore advantageously the router also enters the state  7530  indicating that the router is busy in which it doesn&#39;t accept another bandwidth reservation request for another connection. Once the router identifies the second type of message being a confirmation from the server  1100  transmitted to the client  1000  for the same pair of client and server which confirms, that all the involved routers have successfully reserved the requested bandwidth it moves back to a ready state  7510 . The “R_Busy” state  7530  is for instance needed to filter out any possible retransmissions of the first type of message  7140  and advantageously prevents double updates of the bandwidth reservation at the router. Furthermore in comparison to the previous drawings the connection is terminated by the third type of message  7170  here containing the same bandwidth parameter(s) as the first type of message  7140  which have been for instance saved at the client  1000  and server  1100  which issues third type of message  7170 . As a consequence of receiving the third type of message  7170  the router  7500  decrements its reserved bandwidth. If message exchange takes place on the basis of a reliable network this operation can never fail and therefore a third type of message  7170  cannot be lost and therefore in this case preferably no timer is needed to follow up on the proper handling of this message. The evaluation process and the storage process at the router is indicated by the box  7520 . 
         [0085]      FIG. 8  gives another example of a message flow of an embodiment of a method according to the present disclosure where the message exchange is taking place on an unreliable network, respectively on a network supporting traffic classes for real-time communication. 
         [0086]    In comparison to the message flow shown in  FIG. 4  this message flow includes also like the previous message flow a router  7500  for forwarding the messages exchanged between client  1000  and a server  1100 . As previously explained, when elaborating on the message flow at  FIG. 4  supporting an unreliable network preferably requires closer supervision of the messages exchanged between client  1000  and server  1100  and also precautions at the router  7500 . 
         [0087]    Here also a fourth type of message  4150  is required during the cause of terminating the connection. The reason lies in the requirement of any router update needing three messages one message initializing the communication carrying the bandwidth like the first type of message  7140  and the third type of message  7170 , a second message acknowledging the first type of message like message  1150  and message  8150  “T_FIN_ACK” and a third message to commit the bandwidth change like message  4150 . In this case the router  7500  changes its state to  7530  indicating “R_Busy” in case the router is busy or cannot honor the bandwidth change in case of insufficient free bandwidth the router generates an “S_Error” message as will be explained further below. The bandwidth allocation and evaluation is here further indicated by box  8550  at the router  7500 . 
         [0088]      FIG. 9  indicates the states and state transitions as an example of a state machine associated to the message flow in  FIG. 7  observed from a client side. 
         [0089]    Here following states are possible  7120 ,  1110 ,  4110  and  1130 . 
         [0090]    A state transition from state  1130  to state  7120  takes place corresponding to  9150 : T_OPEN.req (my_server, bw)/conn_bw=bw, T_SYN (to:my_server, bw), start Timer_SYN; whereas a state transition from state  7120  to state  4110  is possible corresponding to  9300 : T_SYN_ERR (from:my_server)/T_FIN (to:my_server, conn_bw). On the other hand a state transition from state  7120  to state  1110  for the client takes place according to  9250 : T_SYN_ACK (from:my_server)/T_ACK_ACK (to:my_server), T_OPEN.cnf (ok), stop Timer_SYN. A further transition possibility between state  1110  and state  4110  exists in corresponding to  9400 : T_CLOSE.req( )/T_FIN (to:my_server, conn_bw), start Timer_FIN. In the case of transition  9100 : T_FIN_ACK (from:any_server)/T_ACK_ACK (to:any_server); transition  9200 : T_FIN_ACK (from:any_server)/T_ACK_ACK (to:any_server), transition  9200 : timeout Timer_SYN/T_SYN (to:my_server, conn_bw), restart Timer_SYN; transition  9350 : T_DATA.req/T_DATA (to:my_server), transition  9350 : T_DATA (from:my_server)/T_DATA.ind; transition  9350 : T_FIN_ACK (from:other_server)/T_ACK_ACK (to:other_server), transition  9350 : T_SYN_ACK (from:my_server)/T_ACK_ACK (to:my_server); transition  9450 : T_SYN_ACK (from:my_server)/T_FIN (to:my_server, bw), transition  9450 : T_SYN_NAC (from:my_server)/T_FIN (to:my_server, bw); transition  9450 : T_FIN_ACK (from:other_server)/T_ACK_ACK (to:other_server); and transition  9450 : timeout Timer_FIN IT_FIN (to:my_server, conn_bw), restart Timer_FIN, the respective states ( 1130 , 7120 , 9350  and  9450 , respectively) are maintained. 
         [0091]    Here when bandwidth reservation is added to the connection management, preferably the necessary bandwidth requirement is given as a parameter to the message  1010 . For instance, the bandwidth may be expressed in raw bandwidth instead of the alternative e.g. a link usage percentage, and may for instance contain a different value for each direction client to server and reverse server to client. Also more elaborated bandwidth description are possible. For instance, a dedicated bandwidth, for which a hard guarantee is provided, and a shared bandwidth for which only a soft guarantee is provided. This bandwidth or a set of bandwidth parameters is also added to the first type of message  7140  and the third type of message  7170 . The bandwidth is for instance saved as a connection bandwidth when the message  1010  is received and then used for both the first type of message  7140  and the third type of message  7170 . A fourth type of message  4150  ensures the correct bandwidth update at the routers  7500 . As an improvement, if the bandwidth parameter of the third type of message  7170  is 0, the fourth type of message  4150  can be omitted. 
         [0092]      FIG. 10  shows an example of a state machine indicating states and state transitions a server can take in an embodiment of a method according to the present disclosure that is explained in a message flow in  FIG. 8 . 
         [0093]    The state machine has the following states and state transitions:  10010  “S_WaitCloseRsp”;  10020  “S_Error”;  1240 ;  10030  “S_WaitOpenRsp”;  7510 ;  8560 ;  1230  and  10040  “S_WaitCloseRsp”. 
         [0094]    State  1240  is initiated by  10100 : T_L1STEN.req/-; and a transition to state  10030  occurs corresponding to  10150 : T_SYN (from:my_client, bw)/T_OPEN.ind (my_client), start Timer_Rsp. A transition from state  10030  to state  10020  occurs by  10200 : timeout Timer_Rsp/stop Timer_Rsp, T_SYN_ERR (to:my_client); and from there to state  10010  corresponding to  10300 : T_OPEN.rsp( )/T_CLOSE.ind( ) occur. 
         [0095]    Furthermore a state transition between state  10030  and state  7510  occurs corresponding to  10450 : T_OPEN.rsp( )/stop Timer_Rsp, T_SYN_ACK (to:my_client), start Timer_ACK. 
         [0096]    Furthermore from there a transition is possible to state  1230  corresponding to transition  10600 : T_ACK_ACK (from:my_client)/stop Timer_ACK, transition  10600 : T_DATA (from:my_client, data)/stop Timer_ACK, T_DATA.ind (data); and from state  7510  to state  8560  according to  10550 : T_FIN (from:my_client, bw)/T_FIN_ACK (to:my_client), start Timer_ACK. Furthermore a state transition from state  1230  to state  10040  takes place by  10700 : T_FIN (from:my_client, bw)/T_CLOSE.ind( ). From there a further state transition to state  8560  is possible corresponding to  10800 : T_CLOSE.rsp/T_FIN_ACK (to:my_client), start Timer_ACK; and back to the starting point from state  8560  to state  1240  a transition is possible according  10850 : T_ACK_ACK (from:my_client)/stop Timer_ACK. 
         [0097]    The respective states ( 10010 , 10020 , 1240 , 10030 , 7510 , 1230  and  10040 , respectively) are maintained corresponding to transition  10350 : T_SYN (from:any_client, bw)/T_SYN_ERR (to:any_client), transition  10350 : T_ACK_ACK (from:any_client)/-, transition  10250 : T_SYN (from:any_client, bw)/T_SYN_ERR (to:any_client), transition  10250 : T_ACK_ACK (from:other_client)/-, transition  10900 : T_ACK_ACK (from:any_client)/-, transition  10400 : T_ACK_ACK (from:other_client)/-, transition  10500 : T_SYN (from:my_client, bw)/T_SYN_ACK (to:my_client), transition  10500 : T_SYN (from:other_client, bw)/T_SYN_ERR (to:other_client), transition  10500 : T_ACK_ACK (from:other_client)/-, transition  10500 : timeout Timer_ACK/T_SYN_ACK (to:my_client), restart Timer_ACK, transition  10650 : T_DATA.req (data)/T_DATA (to:my_client, data), transition  10650 : T_DATA (from:my_client, data)/T_DATA.ind (data), transition  10650 : T_SYN_ACK (from:other_client)/-, transition  10650 : T_SYN (from:other_client, bw)/T_SYN_ERR (to:other_client), transition  10650 : T_ACK_ACK (from:other_client)/-, and transition  10750 : T_DATA.req (data)/T_DATA (to:my_client, data), transition  10750 : T_FIN (from:my_client, bw)/-, transition  10750 : T_SYN (from:other_client, bw)/T_SYN_ERR (to:other_client), transition  10750 : T_ACK_ACK (from:other_client)/-. Also from state  10010  a transition to state  1240  occurs according to  10950 : T_CLOSE.rsp/-. 
         [0098]    Furthermore the server e.g. also receives the bandwidth parameters on the first type of message  7140  and the third type of message  7170 . The state  8560  is introduced in order to preferably cause the server to wait on the fourth type of message  4150 . The sixth type of message  4170  is also preferably protected in its secured transmission by a timer which is started when the sixth type of message  4170  is transmitted and triggers a retransmission if the timer expires. All the timers at the server can be implemented preferably and advantageously in one timer, as they don&#39;t run in parallel. 
         [0099]      FIG. 11  shows an example of a state machine for states and state transitions a router can adopt in the embodiment of the method according to the present disclosure shown and explained in  FIG. 8 . 
         [0100]    Following states are e.g. possible:  7510 ;  11540  “R_Busy_Fin” and  11530  “R_Busy_Syn”. 
         [0101]    An initiation of state  7510  takes place according to  11100 : R_bw=0, err_flag=false. From there state transition to the state  11540  takes place corresponding to  11400 : T_FIN (from:client, to:server, bw)/R_client=client, R_server=server, R_bw−=bw, T_FIN (from:client, to:server, bw). Back from state  11540  a transition is possible corresponding to  11500 : T_ACK_ACK (from:R_client, to:R_server)/err_flag=false, T_ACK_ACK (from:R_client, to:R_server) occurring. A state transition from state  7510  to state  11530  can also take place corresponding to transition  11200 : T_SYN (from:client, to:server, bw), (R_bw+bw)≦MAX_BW/R_client=client, R_server=server, R_bw+=bw, T_SYN (from:client, to:server, bw), or transition  11200 : T_SYN (from:client, to:server, bw), (R_bw+bw)&gt;MAX_BW/R_client=client, R_server=server, err_flag=true, T_SYN_ERR (from:client, to:server); and from there back to the starting point corresponding to  11350 : T_ACK_ACK (from:R_client, to:R_server)/err_flag=false, T_ACK_ACK (from: R_client, to:R_server). Another state transition between state  11530  and  11540  takes place corresponding to  11300 : T_FIN (from:client, to:server, bw)/T_FIN (from:client, to:server, bw). 
         [0102]    The respective states ( 7510 ,  11540  and  11530 , respectively) are maintained according to transition  11150 : T_DATA (from:node 1 , to:node 2 )/T_DATA (from:node 1 , to:node 2 ), transition  11150 : OTHER_MSG (from:node 1 , to:node 2 , . . . )/OTHER_MSG (from:node 1 , to:node 2 , . . . ); transition  11450 : T_FIN_ACK (from:R_server, to:R_client)/T_FIN_ACK (from:R_server, to:R_client), transition  11450 : T_FIN (from:R_client, to:R_server, bw) IT_FIN (from:R_client, to:R_server, bw), transition  11450 : T_FIN (from:other_client, to:other_server, bw)/-, transition  11450 : T_DATA (from:node 1 , to:node 2 ) IT_DATA (from:node 1 , to:node 2 ), or transition  11450 : OTHER_MSG (from:node 1 , to:node 2 , . . . )/OTHER_MSG (from:node 1 , to:node 2 , . . . ); and transition  11250 : T_SYN_ACK (from:server, to:client)/T_SYN_ACK (from:server, to:client), transition  11250 : T_SYN_ERR (from:server, to:client)/T_SYN_ERR (from:server, to:client), transition  11250 : T_SYN (from:R client, to: R_server, bw) &amp;&amp; (err_flag==false)/T_SYN (from:R_client, to:R_server, bw), transition  11250 : T_SYN (from:R_client, to:R_server, bw) &amp;&amp; (err_flag==true)/T_SYN_ERR (from:R_client, to:R_server), transition  11250 : T_SYN (from:other_client, to:other_server, bw)/-, transition  11250 : T_DATA (from:node 1 , to:node 2 )/T_DATA (from:node 1 , to:node 2 ), or transition  11250 : OTHER_MSG (from:node 1 , to:node 2 , . . . )/OTHER_MSG (from:node 1 , to:node 2 , . . . ). 
         [0103]    For instance, the router has to build up states during the process of opening and closing the connection. The default state is  7510  where the router is ready and from where it forwards packets to their destinations. However, if the router receives a first type of message  7140  or a third type of message  7170  the router bandwidth reservation is preferably updating and in the course of doing this the router moves to the states  11530  and  11540  respectively. In case the router is in the initial state  7510  and receives a message  7140  having enough bandwidth for allocation it updates the bandwidth and forwards the message to the server. On the other hand if the bandwidth availability is insufficient the router issues an error_flag to prevent the bandwidth from being updated and an error message is set to the server instead of forwarding the message  7140 . The error_flag preferably may be used to prevent the bandwidth from being updated when closing the connection. In both cases the client and server pair involved in the connection setup is preferably safe to prevent multiple bandwidth update due to retransmissions. Being in the state  7510  in case the router receives the message  7170  also the client server pair is safe as for the message  7140  and the router bandwidth is preferably increased with bw. 
         [0104]    Being in the state  11530 , if a fourth type of message  4150  is received matching the saved client server pair, the error_flag is cleared and the router moves to the state  7510 . If a message  7170  is received matching the saved client server pair the router transits to the state  11540 . Preferably all messages including the message  4150  and the message  4170  are forwarded. With the exception, that once a message  7140  is received for the client server pair that is saved and the error_flag is set. When being in the state  11540  if the message  4150  is received matching the saved client server pair, the error_flag is cleared and the router moves to the state  7510 . In this state all messages including the message  4150  are forwarded. For every connection opening/closing, the router needs to preferably save a state identifying the connection referring to the client and server identities which may consist of address and port. For instance, the simplest router implementation may save a single connection identity as shown in  FIG. 11 . Alternatively, a router could store several connection identities, in which case it may employ one state machine as shown in  FIG. 11  per connection identity it is able to save. In this case each time a message  7140  or  7170  is received which can be stored in a connection identity, the router engages in the states and state transitions shown in  FIG. 11 . In case the router is not able to store the connection identity, preferably the router discards the message  7140  respectively  7170  and takes no further action. 
         [0105]    The following  FIGS. 12 to 21  discuss various examples of errors and their handling according to the method of the discussed embodiments of the method of the present disclosure, which in the same manner may be handled by the system according to the present disclosure. 
         [0106]      FIG. 12  gives an example of an error case potentially occurring in an embodiment of a method according to the present disclosure in further detail in  FIG. 1 . 
         [0107]    In this case for instance the server  1200  may be busy and therefore not able to forward the first type of message  1140  because it is in the state  1230  indicating, that at present the server  1200  is dealing with a different connection. In this case instead of establishing a connection with the application server  1300  it generates an error message  12150  “T_SYN_ERR” which when received by the client  1100  causes the client to transit to the state  1130  where the connection is closed, instead of the state  1110 , where the client would be connected. 
         [0108]      FIGS. 13 and 14  illustrate the use of a timer to supervise the transmission of a message which can potentially be lost or discarded. 
         [0109]      FIG. 13  shows the case, where an error potentially might occur in an  20  embodiment of a method according to the present disclosure which is discussed in more detail in  FIG. 1 . In this case the first type of message may be lost  13140  and therefore will not be received or processed by the server  1200  which remains in the state  1210 . In this case however the first client timer measuring the first predefined time period expires causing a retransmission of the first type of message  1140  to establish the connection between the client  1100  and the server  1200 . The first predefined time period is preferably dimensioned in such a manner, that it allows the server  1200  sufficient processing time to generate a second type of message  1150  as well as sufficient transmission time in both directions. The further handling is as discussed in  FIG. 1 , when the second type of message  1150  is received by the client  1100 . 
         [0110]      FIG. 14  explains another error and its handling that might potentially occur in an embodiment of a method according to the present disclosure discussed associated with  FIG. 4  in more detail. In this case the second type of message indicated with reference sign  14150  is lost. Also in this case a timeout occurs indicated by reference sign  13010  as in  FIG. 13  causing a retransmission of the first type of message  1140 . This message arriving at the server  1200  is detected and due to the state transition caused by the first type of message  1140  received at the first time from state  1210  to  1220  this allows the server to identify that this message  1140  is retransmitted and the source of this message is the first. Allowing server to discard the retransmitted message  1140  without processing, and make a state transition to state  1230  where it is connected and to send a second type of message for confirmation  1150 . 
         [0111]      FIG. 15  explains an example of another error case that may occur in an embodiment of the method according to the present disclosure discussed in more detail in  FIG. 1  in its message exchange. In this case it will be discussed what might occur in case the application at the application server  1300  crashes. Here although the server  1200  has sent a message  1310  it won&#39;t receive a response from the crashed application  1320 . This leads to a timeout  15250  at the first server timer measuring a second predefined time period which in its dimensioning should take into account the message transfer in both directions and an amount of time for the application server to process the message  1310  and generate a response  1320 . Expiration of the first server timer due to the timeout  15250  generates the state  6550  indicating an error, and sends an error message  15150  to the client. A further transmission of a first type of message  1140  will lead to an error message  15140  from the server  1200  and as corresponding message to the application client  15010  in response to error messages  15150  respectively  15140 . In both cases the client will close the connection and move to state  1130 . 
         [0112]    If the application server responds to the server with a message  1320  T_OPEN.rsp, the server notifies the application server that the connection is actually closed using the message  1370  T_CLOSE.ind, and returns to state  1210  S_Listen, where the server is ready to receive connection setup requests. 
         [0113]      FIG. 16  gives an example how an error can be handled in an embodiment of a method according to the present disclosure discussed in its message flow in detail in  FIG. 4 . 
         [0114]    Here also like previously discussed in the case for a reliable network the server  1100  is busy and cannot establish a connection upon request. It consequently generates an error message  12150  to inform the client  1100 . This causes a connection close operation at the client  1100  issuing a third type of message  1150  which is acknowledged by a sixth type of message  4170  issued from the server  1200 . The client then moves to the state  1130 . 
         [0115]      FIG. 17  discusses a potential error case occurring in an embodiment of the method according to the present disclosure where the message exchange is based on an unreliable network as discussed in more detail in  FIG. 4 . As in an unreliable network any message may be corrupted or lost also the second type of message  1150  should preferably be supervised for its proper handling. If this is not the case, the loss may lead to the server being left in an “S_Connected” state  1230  being at first busy while responding with an error message upon request to establish a connection  12150  then however disconnects from the other client indicated by reference sign  17150  and becomes available for a new connection again in the state  1210 . The error message however arrives at the client  1100  too late and after the timeout  13010  that caused a retransmission of the first type of message  1140  which causes the server to open the connection with the application server  1300  and start the transmission of data  1160  which creates a protocol error  17160  as the second type of message  14150  was lost. 
         [0116]      FIGS. 18 to 21  discuss different error cases that may occur in an embodiment of the method according to the present disclosure that in more detail is discussed and shown in  FIG. 8  and the associated explanations. 
         [0117]    There the router  7500  is busy or cannot honor a bandwidth change request due to unavailability of bandwidth and generates an error message due to this situation. 
         [0118]      FIG. 18  shows a first case handling of that situation. Receiving a first type of message  7140  a router  21500  rejects the bandwidth allocation and sets an error flag at  21520 . This leads to the transmission of an error message  20140  to the router  7500  which is forwarded to the client  1100 . The router  7500  sets an error flag at  20540 . On the other hand the client receiving the error message  20540  starts terminating the connection sending the termination upon error message  20170  “T_Fl N_ERR”. Forwarded to the router  21500  this generates an acknowledge message  4170  which upon arrival at the client  1100  triggers the generation of an error message  12020  “T_OPEN.err’. 
         [0119]      FIG. 19  gives an example of the same error case discussed in  FIG. 18  with a slight change of the message flow and handling. Receiving the first type of message  7140  the router  21500  does not set an error_flag at  19520  and does not transmit bandwidth information at the error message  21140  to the client. Contrary to the previous example thus the client  1100  can follow up with a normal connection termination as discussed in  FIG. 8 . 
         [0120]    In this case the router enters a different state in the error case  19530  “R_BusyERR”. The normal connection termination will also free the bandwidth allocation where available. In the case of the example given in  FIG. 19  the message handling is easier and requires a lower amount of messages to be transmitted. In both cases however shown in  FIGS. 18 and 19  the router preferably needs to be adapted to implement some functionality of the server when issuing error messages  21140  and  20140 . 
         [0121]    In order to avoid such a modification of the router, a potential alternative is to forward the error handling to the server  1200  which is discussed in the examples in  FIG. 20  and  FIG. 21 . 
         [0122]      FIG. 20  gives an example of the handling of an error case where the router is busy and the message exchange is based on an unreliable network in an embodiment of a method according to the present disclosure discussed in  FIG. 8 . 
         [0123]    Here similar to the case discussed in  FIG. 18  once receiving a forwarded first 10 type of message  7140  and having no available bandwidth, the router sets an error_flag and forwards new in this case the error message  20140  to the server  1200  which generates an error message  20140  including a bandwidth parameter. A further additional task by the server is to respond to the connection termination upon error issued by the client  1100  by a seventh type of message  4150 . 
         [0124]      FIG. 21  also gives an example of the error handling discussed in association to  FIG. 19 , in this case however the error handling is taking place at the server  1200 . As a modification the protocol in  FIG. 19  is modified in such a manner, that the error message  21140  is forwarded to the server  1200  which will then be responsible to send the error message  21140  and to handle the termination of the connection. 
         [0125]    For an unreliable network, potential alternatives for updating the bandwidth in the router is to do it with the second type of message  1150  instead of  7140  and/or message  4170  instead of  7170 . Here the client/server pair may be saved as before as well as the flag ERR_flag may be set, when the first message  7140  and/or  7170  is received. In this case however the bandwidth parameter will be carried by the messages  1150  and  4170 . In this case of an error, the error message  21140  does not carry any bandwidth parameter and will lead to a connection termination with no bandwidth, because no bandwidth updates were made by messages  1150  and/or  4170 . Thus the message  4150  can be optimized further in this error case. 
         [0126]    Although embodiments of the present disclosure have been described in detail, it should be understood that various changes, substitutions and alterations can be made without departing from the spirit and scope of the inventions as defined by the appended claims.