Improvement of availability and scalability in system of message transfer by method, transparent for application

FIELD: physics, communication.

SUBSTANCE: invention concerns resorts of maintenance of infrastructure of message transfer which during performance abstracts operations of parcel and reception for exchange of messages with terminal point of the partner. Message infrastructure accepts commands from the appendix the message transfers setting guarantees of through delivery; uses mechanisms of transportation for satisfaction of requirements of the given guarantees of delivery, and creates communication between the application of message transfer and mechanisms of transportation for use at an exchange of conferrings. Storage of a state of a session can be supported in connected storehouse which can be, for example, storehouse of a database of the long-term storage or storehouse of storage of the application.

EFFECT: improvement of availability and scalability of the message transmission application by means of improvement of availability and scalability of underlying mechanisms of messages transportation.

71 cl, 4 dwg

 

The technical field

The present invention generally relates to reliable messaging systems. More specifically, the present invention provides systems, methods and computer program products for improving the availability and scalability for secure two-way messaging systems, so that improvements are transparent to the application.

Prior art

The messaging system is becoming more and more popular way messaging. These communication systems include systems from sending e-mail to perform secure transactions, from rooms for friendly chat to various web services, such as shopping in the online store. These systems and application programs have significantly changing demands reliable messaging, security, performance, availability and scalability. Existing systems offer partial solutions that satisfy the specific, limited to combinations of more General requirements.

The traditional system messaging offer limited flexibility in terms of the guarantee (for example, only a single delivery), templates, messaging (e.g., unilateral or using a request/response is or full duplex) and the semantics of the message passing interface (for example, transactional message buffering). Each of these messaging systems usually solves a limited set of requirements for scalability and availability and/or offers little scope for expansion of the system to increase the overall scalability or availability or requires extensive participation application tasks.

For example, consider the following model of two-way communication. The datagram systems typically offer one-sided, without establishment of a communication session, the messaging reliability type "send and forget" and offer little direct support for scalability and availability. These systems offer designers maximum freedom and flexibility to build everything yourself.

TCP (Transmission Control Protocol) provides full-duplex service-oriented communication session. It has a richer, but a fixed set of guarantees delivery (only once, ordered delivery of bytes). The connection status is maintained in data structures in volatile memory device, and the connection cannot ensure the survivability of the system and process failures and multiple network failures, limiting availability.

RCP (Remote Procedure Call) provides half-duplex exchange pattern; some systems limit it to single interactions the IPA request/response, and some provide dialog sessions. In any case, the state of the endpoint is normally maintained in RAM and therefore has limitations to the availability of similar to TCP. While systems of the type request/response without establishment of a communication session can sometimes achieve great scalability (e.g., HTTP-based network "farm"), they usually do not provide the-more-one-time query processing, thus limiting their use idempotent requests. The RPC system is based on the formation of a communication session can provide the repetition of the request with the most-more-one-time treatment, given the slight increase in distance. In some cases, the underlying transport connection are managed by the runtime, allowing for multiplexing with some increase scalability.

Finally, the Queuing system messages usually provide the semantics of only-once delivery. Unlike the datagram, TCP and RPC models, Queuing impose the condition buffering between the two communicating parties, taking into account the additional connectivity and scheduling flexibility. Many Queuing system messages provide long-term persistence, providing additional availability, assuming from the basics of processing and system failures. Some Queuing system also have transaction support; this model can increase the reliability and availability, automatically cancelling partial work and allowing automatic re-processing. These systems typically impose limited storage capabilities, such as requiring the use of private, long-term storage, and transport dependencies that limit the network configuration.

Accordingly, there is a need in the messaging system, which provides enhanced flexibility for the adaptation of application programs to the special conditions and requirements at run time, up until fulfilled the guarantees granted to the application. In addition, there is a need in the messaging system with the above-mentioned flexibility, which can be used to adapt the availability and scalability of applications to the needs of the particular deployment, in a way transparent to the application program.

The invention

In accordance with the above as examples of variants of implementation of the present invention to overcome the aforementioned shortcomings of existing messaging systems. For example, exemplary embodiments of provide the messaging infrastructure during the Oia, which abstracts the operation of sending and receiving messages with the endpoint partner on a number of transport mechanisms messages. The present invention improves the availability and scalability of applications send messages, improving availability and scalability of the underlying transport messages. For example, accessibility is improved by masking many mistakes, providing support for long-term maintenance of state support for clusters, redundancy services, custom lock by time and custom buffer sizes invisible to the application. Scalability is achieved by varying buffer sizes and duplication of services, for example, the service "farms".

In particular, availability and scalability are improved by selecting one of the transport mechanisms messages to communicate with the application send messages at run time. The messaging infrastructure in accordance with the present invention accepts commands from the application send the message, determining (setting) the guarantee end-to-end message delivery, such as at least once message delivery, the most-more-once message delivery, ordered delivery of messages and maintaining the time of validity of the session. Selected by the guarantor and are used when selecting a suitable mechanism for transporting messages at run time without definition (job) application send the message to the appropriate transport mechanism during deployment (input in action). Infrastructure selects at least one transport that meets the end-to-end guarantees message delivery and creates a link between the application messaging and the selected transport mechanism for use in the exchange of messages between the application messaging, and endpoint partner.

In accordance with other exemplary embodiments of the implementation of the present invention, the infrastructure can accept commands from the application send the message indicating the local properties (parameters) reliable message transmission, such as the conservation status of the communication session, the time of validity of the message and transactional message buffering. Local property reliable messaging on the conservation status of the communication session can be supported in the plug-in store, which can be, for example, store background process, database storage long-term storage or storage memory applications. Selection of storage determines the durability of the session state, providing the ability to recover a larger number of failure modes (for example, failure of an applied problem, node failures, and so on), which in turn provides increased accessibility. Similarly, the on-disk store may be able to maintain the best more messages, what is the basis for memory storage, thus improving scalability and availability.

In addition, the local properties of a reliable message transfer can also include the following: buffer quota, which determines the maximum number of messages that will be buffered by the messaging infrastructure; timeout when sending, which unlocks the operation of the parcel after the expiration of the timeout when sending; priority option, in which messages with a higher priority pass before messages with a lower priority; and a custom property for messages such as"poisoners", according to which the number of times, after which the message delivery is interrupted, is configurable to determine when the message is a "poisoner" (harmful).

Additional characteristics and advantages of the invention are formulated in the following description, and will partly be obvious from the description or can be learned in the practical implementation of the invention. The characteristics and advantages of the invention may be realized and attained by means of tools and combinations, in particular those specified in the accompanying claims. These and other features of the present invention will become more apparent from the following description and applications the military claims, or may be examined in the practical implementation of the invention, as set forth below.

Brief description of drawings

To describe the manner in which the above and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above with reference to specific variations in its implementation, which is illustrated by the attached drawings. It should be understood that these drawings depict only typical embodiments of the invention and should not be construed as limiting its scope, the invention will be disclosed and explained, with links to more detail using the accompanying drawings, in which:

Figure 1 illustrates a reliable stack messaging in accordance with exemplary embodiments of the implementation of the present invention,

Figure 2 illustrates a messaging system in accordance with exemplary embodiments of the implementation of the present invention,

Figure 3 illustrates the "life cycle" of communication between the application and the transport mechanism in accordance with exemplary embodiments of the implementation of the present invention;

Figure 4 illustrates an example system that provides a suitable environment for the present invention.

A detailed description of the preferred embodiments

The present invention comprises methods, systems which we and computer software products to simplify deploying reliable applications messaging providing a single programming model to access and use many different mechanisms to transport messages during deployment (operation) one or more application programs. Embodiments of the present invention may contain computer - specialized or General purpose, including various computer hardware, as discussed in more detail below.

Figure 1 illustrates a zoomed-out view of the stack 100A and 100b for reliable message transfer. In the stack messaging without a reliable Protocol 125 messaging Reliable Messaging Stack) application 105, if necessary, to send a message, for example, to another level of 185 application, transmitting a message or series of messages 115 directly to the level of 140 datagram messaging. (It should be noted that the application 105 can refer to any type of application, for example, be of service and in General should be seen as covering the relevant system (structure) applications as appropriate.) Because datagrams are not reliable, messages or message 115 may be duplicated, delayed and/or skipped. For example, in less reliable Protocol transmission of datagrams with the reliability of the type sent and forgotten", message or message 115 may be missed by any the reason, including causes, associated with the mediator 135 between the means 160 and 165 transportation. Accordingly, the application 185 at the endpoint of the partner may never receive the message or messages 115, and sends the application 105 will not know that the message or messages 115 were not taken.

In accordance with examples of embodiments of the present invention, however, stacks 100A and 100b reliable messaging supplied Protocol 125 reliable message transfer. Accordingly, for example, the system (structure) 120 (or alternatively 180) reliable message transfer can ensure that the message or messages 115 sent from the application 105 duly reached their destination in the target point. For example, if the application 105 wishes to transmit a message or messages 115 to 185 Appendix - his partner in the communication session, the application 105 may send a message or messages 115 Send() to the system 120 reliable messaging, where they assign a session and set the sequence number of the message. The communication session identifier matches the communication session between the application 105 and the application 185. In other words, a session refers to a duplex communication session between the two application programs 105 and 185. The numbering in the sequence corresponds to a specific message within a communication session. For example, can sushestvovaniya messages within a single session, taking place between the two application programs 105 and 185, and each message is numbered sequentially in the order sent by the application. In addition, there may be multiple sessions established between the application programs 105, 185, and possibly other application programs (each established session may be the same or different delivery guarantees). Accordingly, each message can be assigned to the session and the sequence number that uniquely identifies a specific session and sequence number in the sequence of transmission of messages within the session.

After the recording session and sequence header on a message 191 and performing other desired channel processing message 191 retain in Condition 190 Session (Session State) in the transmit buffer. Then a copy of the message 191 is passed down through the level 140 transmit the datagram messages that facilitates end-to-end transmission of a message 191, for example, providing routing headers. Message 191 is then passed, possibly through one or more intermediaries, such as Broker 135, each of which facilitates end-to-end transmission of a message 191 in endpoint transfer. Can use the extensible interception mechanism to implement different types of behavior, such as routing, filtering, control is to implement policy and protection. It should be noted that the mechanisms (means) 145, 170, 155 transportation and the types of behavior that are available in the destination terminal message transfer and intermediary 140, 175, 150, can be set either programmatically or through configuration settings.

If the application 105 is specified (set) warranty-less-least-once delivery (described in more detail below), the system (structure) 120 reliable messaging waits for the reception of the acknowledgement from the system (structure) 180 reliable transfer of messages indicating which messages duly adopted. Message 192 is confirmation that the message 191 (for example, message 5 in the sequence) was adopted. Periodically, if the message 192 confirmation is not accepted by the system 120 reliable message transfer, or due to the fact that the copy does not properly adopted by the system (structure) 180 reliable message transfer, or due to the fact that none of the evidence from 180 were not taken at 120, the message 191 transmit again. Accordingly, if the message 191 was missed, delayed or incorrectly routed, for example, a Mediator 135, the system 120 reliable message transfer continues (over a period of time block, described below) to periodically send a message 191 in an attempt to ensure that at least one copy of the informed who I 191 duly adopted by the system 180 reliable message transfer. It should be noted, however, that for similar reasons as described above with respect to message 191, confirmation 192 can be ignored, delayed or incorrectly routed. As such, the present invention provides reliable message delivery for messages 192 confirmation, as described below.

Once the system (structure) 180 reliable transfer of messages successfully receives a copy of the message 191, it sends a message 192 confirmation system 120 reliable message transfer. After receiving the message 192 confirmation system 120 reliable messaging removes from its buffer 190 (make) state of the session copy of the message 191 and stops further transmission. Similarly, the system 180 reliable messaging records in its status 195 communication session that she received a copy of the message 191, for any duplicate messages received by the system 180 reliable message transfer, could be rejected regardless of whether the message has already been delivered to the application 185. Then, the application 185 may be removed from the buffer 195 status (receiving) communication session received message through his team Receive() (to take). If the system 120 reliable message transfer does not accept the confirmation because of his loss, delay or improper routing, re is transferring messages 191 continues, thus forcing the system 180 reliable messaging to send another copy of the confirmation 192. This process may continue until such time as at least one confirmation 192 will not be accepted by the system 120 reliable messaging or until the system 120 reliable messaging will not refuse to repeat and send the indication of the error to the application 105.

System (structure) 120 and/or 180 reliable message transfer can be each made with the possibility of Dialogue 200 (figure 2) in accordance with the present invention and as described in more detail with reference to Figure 2. Dialog 200 is an abstraction patterns (transmission system) messages, in which service (or instances of applications) use Dialog 200 for reliable-oriented communication session with other services. Programmers can use the Channel 220 of the Dialog to access the Dialogs. In addition, the Dialogue 200 provides the infrastructure for reliable messaging and unified programming model, when guarantee message delivery to applications are customizable. These guarantees reliability must be met, or there is a failure in the implementation of the communication session. Design Dialogue 200 provides the appropriate implementation at runtime flexibility to offer additional in the options (properties) subordinate to the maintenance of warranties limitations of correctness), established for the implementation of applied problems. In particular, the application may be provided with varying degrees of availability and scalability, transparent for the implementation of applied problems. In addition, this exchange of messages during a communication session between the applications 105 and 185 may be implemented through a number of types of transport mechanisms (e.g., TCP/IP 160 and HTTP (hypertext transport Protocol) 165), instances of transport links and network topology.

Reliability guarantees provided by Dialog 200, include for-less-least-one (ALO, CSI), the most-more-single (AMO, btes) and ordered (10, UD) delivery. Also available is an additional guarantee "time of validity of the session" (TTL, GVA). Warranty BTS ensures that for any given message is sent from the sending application, the message will be delivered to the receiving application at most once. Because the Dialog 200 is an abstraction, the application is relieved of the need to detect and reject duplicate messages if duplicate messages will violate the semantics of the application. Similarly warranty the software ensures that all messages sent by the sending application, accepted by the receiving endpoint that WWS is bordet applications need to detect lost or misdirected messages, and coordinate their retransmission. Warranty UD ensures that messages are delivered to the receiving application in the order in which they were sent to the sending application. This frees the application from having to deal with the broken order of reception of messages.

Dialogue 200 also provides a communication session guarantee of GVA, which requires that the session dialogue between the partner and the target point partner was completed prior to the expiration of the GVA of the communication session. If GVA communication session expires before the end of the dialogue session, the channels of dialogue are set to "failure", and the application is given notice of the error. Applications can extend the GVA of the communication session, again by agreement of GVA.

Dialogs allow you to use these guarantees message delivery or separately, or in any combination to meet the particular requirements of a given application and deployment. For example, the combination of the three guarantees SW, btes and UD provides only a single ordered delivery the most trusted exchange mechanisms, such as TCP/IP. Unlike typical communication mechanisms and their respective software models, however, these guarantees can be configured without changing the programming model that these applications use.

Dialogue 200 not only takes into account custom warranty, but also takes into account the local properties of the reliable messaging which should be selected and configured independently from each other and independently of the safeguards selected above. These local properties of a reliable messaging belong to two different categories: those that are built-in programming model, and those that pertain to, regardless of the application program. For example, the built-in local properties may include: transactional buffer, which has a semantics, consistency, isolation and atomicity for the application; or link to a profile that associates the profile with the session to provide independent settings. Custom local properties may include the storage configuration of the status of the communication session, the buffer quota, the timeout when sending, custom GVA messages priority messages of the communication session or the detection threshold messages such as"poisoners", as described below.

In accordance with exemplary embodiments of the implementation of the present invention Dialogue 200 provides storage of session state and messages as a replaceable component, called a Repository 260 Dialogue. Because Storage 260 Dialogue is replaceable, third parties may independently create and distribute Store implementation 260 Dialogue. Administrators can read and select Repository Dialog, the actual the key used in a given installation. Accordingly, this mechanism allows greater flexibility to meet the requirements of durability, efficiency, autonomy, and administrative requirements. Store Dialogue 260 may be connected storage that has at least one of: storing in memory, stored in disk storage long-term storage, store in a background process, the non-volatile storage, storage on an optical disc, a magnetic tape, are connected to network storage or removable. Next Store Dialogue can be removed or not associated with a node.

In accordance with an exemplary embodiment of the present invention in one of the implementations provide Storage of Dialogue (for example, storage 260 of Dialogue) in a memory device that retains all of the in-memory state of the application. This store provides very fast access to the state; however, due to the fact that the entire state will be lost if you lost the status of the application process (for example, the application is aborted by the user, it is interrupted by the operating system, for example, because of a failure of the application or system failure, where does the application).

In accordance with another exemplary embodiment, a special implementation Repository Dialog (for example, the storage 260 Dialogue) stores the state of memory CTD is a high dedicated background process. This Store Dialogue provides that the state will remain in the waiver application process, however, by performing the switching process to maintain the state. If the background task fails or the operating system, or computer node fail, all state for the session for which it is responsible, will be lost.

In accordance with another embodiment of the Vault of the Dialogue (for example, the Storage 260 Dialogue) information about the state of the communication session is maintained for a long time in the database, such as a server structured query language (SQL). This is a long state can be maintained when the failure of a computer host or operating system, however, due to the performance of writes to disk, in order to maintain state. One of the advantages of using a database system such as SQL server to maintain the condition is that the installation may already have the tools, methods and processes instead of performing a regular backup and restore critical applications.

The present invention also provides that some Store Dialog can be configured to run on the local computer or on another host. For example, the Storage of long Dialogue type, such as SQL server can be done is but to use the local database server or a database on another node. Another node may be part of a clustered system and, thus, to have a very high availability.

The present invention also provides such multiple store (or configurations (sets) stores)that can exist at the same time, to suit the specific characteristics of deployment used by the application or applications. In addition, the application configuration can be changed to use a different repository or set of repositories)to accommodate changes, such as the requirement of increased load or capacity (capacity), in order to take advantage of the new features of the store or to meet other requirements of the deployment environment. In addition, different conversations in the same application may have different configuration requirements. The dialogue allows you to configure each session individually. For example, some sessions within the application can work best with state storage long-term storage, while other sessions may work best with a volatile state storage. Store Dialog can be configured using the profile (as described below) or defined in the application code.

the other custom property the proposed Dialogue 200 is a buffer quota. Dialogue 200 buffers the message in the sending and receiving applications. This buffering increases the autonomy of these two applications, allowing the party or to send or receive messages to or from their local buffers, even if the other party fails (does not work) or unreachable, for example, separation of the network. For example, it may continue to send messages even though the other party is temporarily unavailable, that is not running or unreachable. This is accomplished through the accumulation of messages in the local buffer 250 parcels (Send Buffer) until such time as they will not be able to be successfully transmitted. Similarly, the application 205 may receive messages that have been previously buffered in the buffer 245 reception (Receive Buffer), even though the application that sent them, now may not be performed. Dialogue 200 provides custom buffer quota, which determines the maximum number of messages (quota on the size of messages that will be buffered by the system. Accordingly, this limits the amount of space used by the State 235 Dialog State), and limits of local resources that can be used by the other endpoint. It also enables the messaging system to reserve space in memory), sufficient for the application to locally buffer the specified number of messages. Dialogue 200 also provides for minimum buffer quota, which determines the minimum reserved number of messages that are buffered by the messaging infrastructure, which in combination with the maximum message size specifies the minimum number of bytes that will be buffered by the messaging infrastructure. The buffer quota can be configured by profile (as described below) or defined in the application code.

Dialogue 200 also provides a custom property time block when sending. When the message is sent, it is put in Storage 260 Dialogue/buffer 250 parcels. If the buffer is full, that is, if achieved buffer quota, the request to Send() 210 is blocked until then, until timeout when sending, or in the buffer becomes available space (area) to save the message. The area becomes available in the buffer when the message is successfully sent and confirmed by the receiving endpoint, and more there is no need to repeat for the local endpoint. If an area becomes available before they expire timeout when sending requests to Send() 210 is completed in the usual way. If the lock time is when the package expires before than the area becomes available, an exception occurs, providing a notification to the application that a message cannot be successfully buffered (captured). Accordingly, the application may try later this operation. Custom timeout allows applications to choose the degree of responsibility on the basis of ease of blocking. Timeout when sending can be configured by profile (as described below) or defined in the application code.

As mentioned above, the Dialogue 200 supports the guarantee of GVA for end-to-end communication session. Dialogue 200 also provides an optional message "Time of Validity of the Session, which is configured as a local property. Message GVA requires that the transmitted message must be successfully accepted by the receiving endpoint within the time specified in GVA, otherwise the application 205 is passed to the error. Dialogue 200 also provides a custom extension for message GVA. Accordingly, when GVA expires, the transmitting application 205 is transmitted to the notification. The application 205 then has the choice to end the conversation or extend GVA messages. Similarly, the timeouts when sending GVA can be set by application code or set indirectly using about the īle.

Another feature provided by Dialog 200, was appointed an optional priority. All messages in the Dialogue box 200 have the same priority. However, when messages from a variety of Dialogs available for transmission, Dialogues with higher priority are given precedence over Dialogues with lower priority when sending messages. Similarly, when messages are available for delivery to the receiving application messages with higher priority are accepted before messages with lower priority. Priorities can be set by application code, or indirectly using profiles, described below.

Dialogue 200 also provides optional transactional buffering messages. When Dialogue is used for transactions, the local buffers of the sending and receiving of messages act as administrators resources for the transaction. In this case, the received message within the transaction, are considered conditionally delivered (remote buffer parcels), subject to the outcome of the transaction. Similarly, messages sent within the transaction are conventionally captured (added to the receive buffer), subject to the outcome of the transaction. If the transaction is committed, these conventional clamps and delivery messages become permanent. If the transaction is aborted, these conditional operations are cancelled so as if they never happened. Like other transactional resource administrators warehouse dialogue are responsible for ensuring isolation of transactions for conventional buffer operations (for example, recorded messages are not visible outside the transaction) and the atomicity of a transaction with a transaction is completed under the control of the administrator of the transaction.

Transactional buffering simplifies the development of correct messaging application (e.g., which make the correct state transitions even in the face of failures or concurrent activity). Applications can use this property to coordinate messaging and local processing of messages. For example, the application can receive and process the message within the transaction. This processing of the message may include reading and updating one or more database transactions, as well as sending one or more messages in the dialogues included in the transaction. If the transaction is aborted, all the work is cancelled. In particular, messages sent conventionally, void, i.e. the partners in the communication session will not see these partial results, and the message remains available for delivery. The latter allows to process the message within a new transaction. When the transaction is complete, in which these actions are unchanged, including removing received message and buffering messages sent. The net result is only a single-message processing. Transactional buffering is a local property of the Dialog whether the application that uses this property, completely transparent to the application of his partner session.

In accordance with exemplary embodiments of the implementation, and as described below with reference to Figure 2, the endpoint of the sender, as you call Send() 210, the message is conventionally placed in the Storage 260 Dialogue. If you make a transaction, the message is transferred to the Storage 260 and is made available for transmission to the endpoint of the partner. If the transaction fails, the message is rejected. In the receiver, as you call Receive() 215 (or Delete), the message is conventionally removed from the Storage 260 Dialogue. If the transaction is committed, the message is permanently deleted from the Storage 260. If the transaction fails, the message remains in the Storage 260 and is available for re-delivery. Transactional reception takes into account only single-process messages.

It should be noted that although transactional buffering is a common property systems, Queuing, these systems typically require storage long-term storage. Dialogue 200 provides the same semantics tranzac the s regardless of the durability of the Storage 260 Dialogue, providing the same programming model in all cases. For example, store in RAM provides transactional semantics, participating as a transactional resource Manager. Dialogue 200, however, allows the implementation of applications to be isolated from the details of the deployment, including details associated with the transportation and connectivity characteristics, routing messages and manage the status of an endpoint.

Other property provided by the Dialog 200 is an optional feature of the message-"the poisoner". As mentioned above, when the message is accepted and processed as a transaction and when the transaction fails, the message remains in the Storage 260 Dialogue and is available for re-delivery to the application. Sometimes the problem that causes the transaction to abort, is short-lived, for example, the blocking time due to deadlock, and delivery, and post processing is successfully performed in the next attempt. If the delivery attempt for a given message repeatedly cause abnormal termination, the message is treated as "poisoner". Dialogue 200 provides a way to configure the number of times the emergency stopping operation when delivering messages must be executed before the message is considered the AK "poisoner". When the message-"the poisoner" is detected, the application is passed to the error message, and additional attempts to process the message are suspended until such time as the application will not perform corrective action. This ensures that processing resources will not be wasted attempting to do the work, which can never be successful or can only be successful after some intervention. Detection message-"the poisoner" can be configured by profile (as described below) or defined in the application code.

Optional feature (property) profile provides a named set of configuration parameters Dialog. As described above, there are many custom features (properties) of the Dialogues, such as the buffer quota, timeout, storage, etc. in Addition, the Dialogue 200 provides safeguards custom message delivery, for example, SW, btes and UD, which codes the application may independently determine the minimum level required guarantee of delivery, which if necessary can be increased by setting. The profile provides a way to group common settings Dialogue and access these settings by name. The following implementation of the Dialogue 200 allows the selection of profiles by flowcontrol applications so admins have control over the settings each time you deploy. When creating or making Dialogues applications refer to the profile by name, and all settings are as specified in the profile to create a Dialog 200. The settings can be set directly as part of the application program as a code or other programming constructs. Profiles can be associated with the program indirectly referenced in the code or by any other programming constructs, so that the profile values can be set independent of the application programs. Profile values set directly, override the values of the profiles defined indirectly through links on the profile.

Because the Dialogue 200 provides for any combination of these features (properties) and guarantees independently from each other, the Dialogue 200 can be configured to suit any configuration of the connection of the programming models with strong communication, such as Transmission Control Protocol (TCP) and Remote Procedure Call (RPC)programming model with a flexible coupling, similar to the datagram and queues. In addition, the Dialogue 200 effectively supports various models of two-way messaging (MEASURES, MDUS), such as one-way, half-duplex (single request/response to more complex models) and the most complex - duplex communication. Accordingly, the Dialogue 200 takes into account the unifying programming model bilateral relations.

Figure 2 illustrates the operating characteristics of Dialogue 200 in accordance with exemplary embodiments implementing the present invention. Application programming interface (API) 220 Channel Dialog Channel) is provided as an abstraction for the application 205. As described above, the Dialogue 200 uses the message transport Protocol, such as WEB Service Reliable messaging (WS-RM), which defines the sequence of messages. The sequence defines a set of unidirectional messages during the session. Two such sequences are combined to form a dialogue, one sequence in each direction between the two parties communicating. When you call the Send() method (send) Channel 210 and 220, the message is passed as a parameter to the Send method 210, remain in State 250 Parcels (State Send) and unique mark timestamp with monotonically increasing sequence number of the message in accordance with the order in which the message was sent.

Message 255 bufferinput in State 250 Parcels to maintain the status of individual messages 255 in the follower of the spine. At this point we can say that the message is "captured" in State 250 State), and the Send() method 210 returns to the application. More specifically, the Send() method 210 receives one message as a parameter. This is the message that is passed to the Send buffer 250 (send) to mark a time stamp with a serial number and the subsequent or simultaneous storage in the vault Store 260. It was at this point the message is considered "fixed" (captured), and the Send() method 210 is completed. The repetition of this query with other messages leads to a sequence or partial sequence of messages 255.

State 235 Dialog State) contains buffers 250 and 240 sending and receiving (Send and Receive), respectively. State 235 Dialogue manages and maintains this invariant information as the Conversation ID, warranties specified for the application, and the endpoint address of the partner. State 235 Dialogue also manages the information session, such as the next sequence number outgoing transfer and status verification. Additionally, configuration data, such as GVA Dialogue, lock by time, location of stores, etc. are supported in a State 235 Session Dialog Session State).

As soon as the message is recorded (captured), the Protocol (Protocol) 270 may process and transmit the captured message, for example with benie 275, accordingly, through the Port 285. Programming model and infrastructure at run time for Dialogue 200 provides a flexible and efficient resolution model for an endpoint. The model, as a minimum, ensures that these two endpoints were sufficiently resolved to ensure a reliable exchange of messages. In particular, the Protocol 270 can be used to insure before delivery of the initial message in the dialogue processing that both endpoints support basis, sufficient to guarantee the uniqueness of the target point and the correct correlation of messages through Dialogue 200 and its corresponding communication session. This is required, for example, in order to ensure that the message is reliably delivered to a single partner session to ensure the most-more-one-time-delivery. This permission endpoint may be based on many factors, including an identifier that identifies the application partner (for example, a uniform Resource Identifier (URI)that is used by the Creator of the Dialogue 200, local configuration, routing data in the headers of the message broker configuration and application configuration.

It is important to note that the implementation of 205 application there is no need to deal with the details of the authorization endpoint Dialogue. Infrastru the tour for Dialogue 200 performs the resolution process to coordinate with the initiating endpoint, to ensure that there is a unique selected peer to peer endpoint for the session. This is done when necessary and is transparent to the implementation of 205 application.

The resolution of endpoints at run time for Dialogue may also be provided to ensure the achievement of the objectives for the delivery of messages at the same time providing flexibility to achieve correct execution in a wide range of network configurations. This feature supports flexible deployment of applications in a variety of configurations to meet the requirements of scalability, availability, security (e.g. firewall) and efficiency. The service deployment configuration include, for example, "farm" applications (e.g., large-scale exact copy) and sections of the application (for example, for separation processing according to the number of the customer or geographical area). "Farm" applications and sections can be used separately or together. For example, the application can be deployed to use dependent data routing applications section, which in turn consists of a farm of application servers.

The Protocol 270 also determines the type of the end-to-end guarantees, and local properties are defined by the application 205, regardless of the method used to perform the resolution of the target point and, described above. If the application 205 specifies the security of software, Protocol 270 stores a copy of the message 275 in the buffer 250 parcels (Send Buffer) Dialogue up until the Protocol 270 not receive a positive acknowledgement from the receiver (not shown) indicating that the message 275 were duly taken. When the Protocol 270 receives a positive acknowledgment from the receiver, it makes a record of this fact in State 235 Session and deletes the message from the buffer 250 parcels. If the Protocol 270 does not make a positive confirmation within a specified period of time block to repeat the Protocol retransmits a copy of the same message 275 with the same sequence number of the message. Dialogue 200 can repeat this process many times and can use the strategy of delaying the recurrence after the expiration of the timer, to avoid additional congestion in the network. If confirmation is not made within the time period specified in accordance with the message of GVA, an error occurs that you want to share a sending application 205 that the warranty cannot be satisfied.

When the message 280 dialogue is accepted, the Protocol 270 copies the message into a state 240 receive buffer. The Protocol 270 also writes the next expected sequence number of the message. When the message 280 is accepted, if the guarantees Dialogue 200 including the indicate in itself BTS the message sequence number for the incoming message 280 is compared with a set of sequence numbers of messages that have arrived earlier, which, as mentioned above, stored in state 240, the receive buffer. If the set already contains a matching sequence number, the message 280 is considered a duplicate and is discarded; otherwise, the message 280 is placed in a local buffer 240 reception for further reference.

If the guarantees include the software, the Protocol 270 sends unrelated to the sequence, completed selective positive confirmation message 280 to the endpoint dialogue partner. This confirmation should include the sequence number of all messages that you have received to date during the session. A brief note, which includes a set of ranges of the sequence, can be used to save the size of the message. If the specified warranty does not include OUD, the message 280 is immediately made available for delivery to the receiving application 205 through the Channel 220 reception (Receive Channel). In particular, the application 205 sends a notification that the message is available for reception. The application 205 may then call Receive() 215, then the following message is available for delivery, convey to the application 205, and can be considered that the "delivery" has occurred.

If the Ana warranty UD, the sequence number of the incoming message 280 is compared with the next expected sequence number. If the sequence number is less than the next expected sequence number, the incoming message 280 reject. If they match, then the incoming message 280 immediately make available for delivery to the receiving application 205, and the next expected sequence number is set to the number of the next missing messages. If the sequence number is greater than the next expected sequence number, then the behavior depends on if there is also the guarantee of MT. If the warranty the software is not set, the message 280 immediately make available for delivery to the receiving application 205, and the next expected sequence number is set to one greater than the sequence number of the incoming message 280. If set to guarantee the software, the message 280 is not made available for delivery to the receiving application 205, but remains in the buffer 240 reception. Accordingly, if they do not match, it is assumed that at least one other message with a lower sequence number has not yet been made. When all such missing with a smaller number of messages received, then a continuous set of messages is made available for delivery to the receiving application in the appropriate sequence, and following the th expected sequence number is set equal to the missing number of the next message.

As mentioned above, when a message is available for delivery to the receiving application 205, a notification is issued to the host application 205. The receiving application can then call the method 215 Receive() on the Channel 220 of the Dialogue, to accept delivery of the next available message. Receive() can be called multiple times to take every available message in turn. To ensure ordering, event notifications are delivered consistently. Accordingly, when a message is available for delivery to the application 205, a single event notification is delivered to the application 205 by calling the application code that has been pre-registered with the event 200 Dialogue. While this request to the application code will not return a result, no other requests to this application code will not be made, even if other messages are available for delivery. Within this application code, the application 205 will usually call Receive() 215 Dialog to receive the next available message.

As also described above, when you call Send() 210, the number of messages that are at this time in the buffer 250 send (Send Buffer), is compared with a given buffer quota. If it exceeds the quota, the caller Send() 210 is blocked on the event, or until the area becomes available or until the timeout when on ylke will not be exceeded. When the area becomes available in the buffer 250 send, buffer checks whether there are any callers that are waiting to send a message. If there is, then calling the Send() method 210 is released again and can send messages.

All of the States for Dialogue 200, including those that are in the buffers 250 and 240 messages in the Channel 220 and the Protocol 270 can simultaneously be supported in the Storage 260 Dialog Store). Store 260 Dialogue should contain the most recent time the update information. This ensures that the Status 235 Dialog State) has the properties of durability Storage 260 Dialogue and allows all the features (properties) to function independently from the Storage 260, which is in use. For example, placing the message 280 to the buffer 240 reception, you can enable recording on the disk in the Storage 260. To assure, confirm send only after the message has been recorded in the Storage 260. This ensures, for example, that either the sender or the recipient always has a copy of the message. Similarly, on the side of the parcel Send() 210 can be completed only after the message has been recorded in the Storage 260.

As mentioned above, the Storage 260 of the Conversation can be attached storage, providing enormous flexibility to meet the requirements of durability, e is the efficiency, autonomy and administrative purposes. For example, the Storage 260 may be selected from one of the numerous vaults within the same structure, which includes the following: implementation of the Store Dialogue in RAM, which retains all of the in-memory state of the application; special Store implementation Dialogue, which stores the state in a memory separate background process; or the implementation of database storage long-term storage, such as a server structured query language (SQL). Various dialogues within the same application 205 may use a variety store. In addition, the present invention also provides that some Store 260 Dialogue can be configured to run on the local computer node or another node.

Because the Dialogue 200 acts as an agent on behalf of the application 205, the application 205 is isolated from changes in connectivity. This allows, for example, a batch style processing when the application starts, it sends and receives some messages and then exits without having to wait for the other endpoint to answer or even a point when it should be available. Next message delivery can be planned with great flexibility, should only cater to a variety of guarantees delivery and local CCA is Enestam (properties), for example GVA message or session. For example, subordinated to the guarantees delivery Dialogue 200 can stretch peak load messages for a certain period of time (load balancing) or otherwise move the message on a more cost-effective time to wait until the resource becomes available, take into account the priority of the message or Dialogue, etc. regardless of the application 205. In addition, the Storage 260 provides opportunities to quit and relaunch the application 205. Batch processing, planning, as well as the completion of the application and re-launch increase the availability and scalability of the system.

In addition, as mentioned above, the application 205 may indicate that the operations Send() 210 or Receive() 215 were transactional in relation to the buffers 250 and 240 Dialogue. This allows the application, for example, to take the message to send some messages in one or more dialogs and update the table of applications - all within a single transaction. In this use of transaction it is just a local notion and not transferred to another termination point.

The dialogue also provides the ability to failover at run time, which can be automatically restored (masked) many errors 265 without calling the implementation of the application. The application can be the t rely on the reception of the established characteristics (i.e. installed warranty and properties) for the Dialog 200. If the infrastructure for Dialogue 200 or Protocol 270 determines that the installed features can no longer be satisfied, the dialogue is translated in the status of "failed"and there is an error event, allowing additional corrective action, independent of the main code of the application or even application 205. If an error (failure) 265 can be fixed (status restored), the dialogue can be placed back in service. Unrecoverable failures, that is, errors that cannot be recovered, can lead to Conversation ends 200 and notification applications. This scheme follows the model of the "fail - fast recovery", which is fundamental for the development of reliable applications.

Failures in survivability may include the following:

damaged, lost, duplicated or delayed messages; failures of transport networks; failures; failures Resellers and system failures. As mentioned above, since the Dialogue 200 provides an abstraction for the application and maintains its own buffers and store, Dialogue 200 also supports applications and environments with intermittent connectivity. Dialogues can also adapt to changing environments, such as changes in the network topology, security contexts through re-negotiation or PE is Emesene in the memory of the endpoint.

Dialogue 200 may automatically try to repair these errors, at its discretion, for example, again sending the message. Alternative or in addition, the Dialogue 200 may send a request to a third party, such as the system operator or the diagnostic program, and requesting assistance for recovery. This can be, for example, a simple human intervention to restore the broken connection in the network, or perhaps an automated repair process. In any case, once the failure is restored, the Dialogue 200 may continue to send messages. This, together with other properties, availability, provides long-lasting Conversations. If, however, the error cannot be resolved by Dialogue 200 or through the intervention of some other third party, an error message should be passed to the application 205, which is used to initialize the dialog.

Applications can be configured to use Storage 260 Dialogue, to maintain a Dialogue with the waiver application process and re-launch. Some store 260 can further prevent systemic failure and re-start (re-start).

Other transmission errors can be handled automatically by a combination of error handling specific region and the base support for the re front and messages as explained above. Examples include errors resulting from the expiration of the protection mandate or policy. If the message transmitted during a secure session, causing the error due to the expiration of the mandate, the Dialogue 200 may re-negotiate the mandates protection and clear (delete) the error dialogue. When the processing of the dialogue is restored, buffered messages will be resubmitted with updated mandates on the basis of standard process repeats.

Also as mentioned above, the scheme and the infrastructure for Dialogue 200 allows the runtime to dynamically adapt the Dialogue 200 to changing execution environment. This can be ensured in a transparent manner for the implementation of the application and support the existence of long-lasting Conversations and applications with a high degree of availability.

The above described combination of error handling (which can be connected), repeated transmission and delivery and recovery model errors allow Dialogs to adapt to many environmental changes. These changes include, but are not limited to, changes in policy (for example, the secrecy of the message), change the Protocol (e.g., support for new security protocols), changes in network topology (for example the EP, adding or removing routers or firewalls), changes in deployed applications to handle the increased load (e.g., presenting "the farm" and/or sections of the application) and moving in the memory endpoint dialogue and bound state (for example, recovering from catastrophic errors). It also allows for scalable features (properties) deployment, which include support from the smallest to the largest. For example, the Dialogue 200 supports zoom in, zoom out, duplication or division of the application, transparent to the application implementation.

Figure 3 illustrates the "cycle of life" and the state of the Dialog 200. Dialogue 200 can be in one of the two main state - Active 320 or Inactive 360. If the Dialogue 200 Active 320, the object 220 channel dialog Channel) is in memory, otherwise, if the Dialogue 200 Inactive 360, Dialogue there is only 200 in the Storage 260 Dialogue. Manage system resources occurs through the Deactivate 350 and Reactivation of 340 processes that can occur manually or automatically. For example, deactivate 350 may occur manually, if the application calls Distribution (Dispose), or automatically due to inactivity time at which expire a certain period of time, when there is no exchange of messages by the mi channel dialogue. This channel can be de-activated (corresponding objects free the memory), thus freeing up memory for other programs.

Reactivate 340 may occur manually, if the application requests a Channel from the Administrator Dialog Manager) (not shown), or Reactivate 340 may occur automatically if the session a new message arrives. Each dialogue by the Administrator Dialogue is assigned a unique identifier ID for Creating 310 Dialogue. This ID is passed from the application 205 to the Administrator Dialogue on request to Reactivate 340, and the administrator of the Dialogue uses the identifier to determine the state of the dialogue and re-initialize the channel. Interfaces deactivate 350 and Reactivate 340 allow the system to limit the processing resources associated with Dialogs that are not actively used for sending outgoing messages or incoming message. This allows the infrastructure to engage appropriate resources except those that are associated with the Storage 260 Dialogue. In addition, this scheme allows for the planning of resources, including: scheduling transmission of the message based on priority or availability of the resource; batching messages for more efficient transmission; scheduling delivery of the message based on priority and availability of the resource; and packaging the message delivery for more efficient processing.

Operation "Create" 310 Dialogue is controlled by the Administrator of the Dialogue and can be initialized by the application, which calls the function "Create" 310. Alternative messaging system can initialize the Creation of 310 Dialogue after receiving the report from the other endpoint, indicating the need for a new dialogue. In this case, the system notifies the application 205 that requires dialogue. The application 205 can then call the method Accept (accept) the Administrator of the Dialogue to accept the request for dialogue, and to cause the Creation of 310 Dialogue, or it can call Reject, the Administrator Dialogue, to deny the request dialogue. Administrator Dialog also controls the disassembly (Teardown) 330, which can be initialized due to a couple of reasons. One reason may be that the session has completed successfully, that is, both parties have fulfilled sending messages and more messages left. Another reason for dismantling 330 may be that the Dialogue 200 is interrupted, for example, the application has called the function Terminate() (to Finish), or from endpoints partner adopted indication of completion. When one party ends the conversation, the message is sent to the other party to indicate this. There is no reliability for the communication, this is just an attempt to inform the other party that the conversation was finished. Completion implies that no further exchanges of messages is no longer within the dialog session.

Although the description of the invention defines dialogue as duplex communication mechanism in which messages applications can be during the session sent and accepted by both partners endpoints, another variant of implementation of the example includes a simplex model. In the corresponding embodiment, one endpoint in the session only sends messages application and does not accept application messages from endpoints his partner, and endpoint partner session only accepts messages application, but does not send application messages. Apply the same custom warranty and local properties of the endpoints, as in the dialogue. The implementation changes that sends the endpoint of the buffer 240 appointment is not required, and the endpoint of the reception is not required buffer 250 package.

Options for implementation in the scope of the present invention also include machine-readable media for transferring or storing executable computer commands or data structures stored on them. Such machine-readable media can be any available means to which m is should be accessed using the General-purpose computer or a specialized. By way of example, and not limitation, such machine-readable media may include random access memory (RAM), a persistent storage device (RAM, ROM), electrically erasable programmable ROM (EEPROM EEPROM), CD-ROM or other storage device on an optical disc, a magnetic memory disk or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form executed by the computer commands or data structures and which can be accessed through the computer's General purpose or specialized computer. When information is transferred or provided over a network or other communication connection (or hardware, wireless, or combination of hardware or wireless) to a computer, the computer properly considers the connection as read by the computer credut way, any such connection is properly called the machine-readable medium. A combination of the above funds must also be included in the scope of machine-readable media. The computer performs the commands include, for example, commands and data, which have a universal computer, a specialized computer or a specialized processing device to perform the some what function or group of functions.

Figure 4 and subsequent discussion is intended to provide a brief General description of a suitable computing environment in which the invention can be implemented. Although not required, the invention will be described in the General context for executing computer commands, such as program modules, executed by computers in network environments. In the General case, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement a specific abstract data types. The computer performs the commands associated data structures, and program modules represent examples of program code for executing steps of the disclosed methods. The particular sequence of such executable commands or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.

Specialist it is clear that the invention may be practiced in network computing environments with many types of configurations of computer systems, including personal computers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PC, mini-computers, General-purpose computers and the like, the Invention may also be implemented is tulino in distributed computing environments, where tasks are executed local and remote processing devices that are linked (or hardware connections, wireless connections, or a combination of hardware or wireless connections) through a network of information exchange. In a distributed computing environment, program modules may be located in local and remote memory storage devices.

With reference to Figure 4 shows as an example system for implementing the invention includes a General-purpose computing device in the form of computer 420 General purpose, includes a processor 421, a system memory 422, and a system bus 423, which connects various system components including the system memory 422 and the processor 421. The system bus 423 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus and a local bus using any of a number of bus architectures. The system memory includes a persistent storage device (RAM, ROM) 424 and RAM, RAM) 425. The system basic input/output system (BIOS) 426, containing the basic routines that help to transfer information between elements within the computer 420, for example, during start-up, may be stored in ROM 424.

The computer 420 may also include the drive 427 on the gesture is Ohm drive for reading from and writing to a magnetic hard disk 439, drive 428 magnetic disk drive for reading from or writing to a removable magnetic disk 429 and the memory 430 of the optical disk drive for reading from or writing to removable optical disk 431 type CD-ROM or other optical medium. Drive 427 on the hard disk drive 428 on the magnetic disk and the drive 430 on an optical disc associated with the system bus 423 interface 432 of the hard disk drive, interface 433 storage on a magnetic disk and interface 434 drive on an optical disc, respectively. The drives and their associated machine-readable media provide nonvolatile storage of CPU commands, data structures, program modules and other data for the computer 420. Although the example environment described herein employs a magnetic hard disk 439, removable magnetic disk 429 and removable optical disk 431, other types of machine-readable media for storing data can be used, including magnetic cassettes, memory cards, digital versatile disks, Bernoulli cartridges, RAM, ROM, etc.

The software contains one or more software modules may be stored on the hard disk 439, magnetic disk 429, optical disk 431, ROM or RAM 424 425 including an operating system 35, one or more application programs 36, other PR the software modules 437 and data 438 programs. The user can enter commands and information into the computer 420 via the keyboard 440, the control device position 442 or other input devices (not shown), such as a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processor 421 via the interface 446 serial port connected to the system bus 423. Alternative input devices can be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). Monitor 447 or other display device is also connected to system bus 423 via an interface, such as the video card 448. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.

The computer 420 may operate in the linked in network environment using logical connections to one or more remote computers, such as remote computers a and 449b. Remote computers a and 449b may each be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above in relation to a computer is Theroux 420, although only storage device 450A and 450b and their application programs a and 436b were illustrated in figure 4. The logical connections depicted in figure 4, include a local area network (LAN) 451 and the wide area network (WAN) 452 that are presented here by way of example, and not limitation. Such networking environments are common in offices or computer networks in the enterprise intranet and Internet. When using in a network environment LAN computer 420 is connected to the local network 451 through a network interface or adapter 453. When used in a WAN network environment, the computer 420 may include a modem 454, wireless connection or other means for establishing communications over the WAN 452, type the Internet. Modem 454, which may be internal or external, is connected to system bus 423 interface 446 serial port. In the linked in network environment, program modules depicted in relation to the computer 420 or parts thereof, can be stored in the remote memory storage device. It should be understood that the illustrated network connections are only examples and can use other means for establishing communications over the WAN 452.

The present invention may be embodied in other specific forms without discontinuing its size or material properties. Describes the options is sushestvennee should be considered in all respects only as illustrative and not restrictive. Scope of the invention, therefore, is defined by the attached claims and not the previous description. All changes that fall within the meaning and range of equivalency of the claims should be included in its scope.

1. The method for selecting at least one transport messages to communicate with the application messaging during its execution, and referred to the selecting is performed in the messaging infrastructure at run time, which abstracts the operation of sending and receiving messaging with end point partner on one or more of the available transport mechanisms messages containing the steps:

receive one or more commands from the application messaging that define one or more guarantees end-to-end delivery of messages that should be used when selecting at least one suitable mechanism for transporting messages at run time, without determining the application messaging, at least one suitable mechanism for transporting messages during deployment, one or more guarantees end-to-end delivery of the message contains at least one of the following: at least once a message is delivered at most once message delivery is tion, message delivery in order parcels, and the time of validity of the session

choose at least one suitable mechanism for transporting messages from the available mechanisms of transport of messages to meet the requirements of one or more guarantees end-to-end message delivery, specified in one or more commands received from the application messaging, and

creating a link within the messaging infrastructure between

application messaging and the selected at least one suitable mechanism for transporting messages to exchange messages between the application messaging, and endpoint partner.

2. The method according to claim 1, additionally containing phase:

receiving one or more commands from the application send messages that indicate one or more properties of the local reliable message transfer, and one or more local reliable message transmission contains at least one of the following: maintaining session state, the time of validity of the message and transactional buffering messages.

3. The method according to claim 2, in which the session state persistence has plug store.

4. The method according to claim 3, in which the plug store contains at least one of: maintaining the operational memory is, save on disk for long term storage, preservation in a background process, stored in a nonvolatile storage memory, optical memory, magnetic tape connected to the network, memory, or removable memory device.

5. The method according to claim 4, in which the plug-in repository contains a repository that is remote from the messaging infrastructure.

6. The method according to claim 2, in which the properties of a local reliable message transfer additionally contain the maximum buffer quota, which determines the maximum number of messages that must be buffered by the messaging infrastructure, and which, when combined with the maximum message size determines the maximum number of bytes that must be buffered by the messaging infrastructure, a minimum buffer quota, which determines the minimum reserved number of messages that must be buffered by the messaging infrastructure, and which, when combined with the maximum message size determines the minimum number of bytes that must be buffered by the messaging infrastructure, a timeout when sending, which unlocks the operation of the parcel after the expiry of timeout when sending and messages with higher prioritetiniu advantage in the transmission and delivery compared to messages with lower priority, and a custom property of the response message is"poisoners", in which the number of times that message delivery is interrupted, is configurable to determine when the message is a "poisoner".

7. The method according to claim 2, in which the property transactional buffering messages for local reliable message transfer is available regardless of the duration of storage of session state.

8. The method according to claim 1, wherein the connection includes a channel buffer status of the session, the Protocol and attached storage.

9. The method according to claim 8, in which one or more of these guarantees end-to-end delivery contains at least one message, wherein the Protocol periodically sends a copy of the previously sent messages to the endpoint of the partner after the expiration of the retry interval until will not be accepted confirmation.

10. The method according to claim 9, in which one or more of these guarantees end-to-end delivery further comprises a time of validity of the session in which, if the confirmation is not made within the specified time the validity of the session, no further repetitions are not doing, and the indication error is passed to the application that relays messages.

11. The method according to claim 9, further comprising stages:

take property with respect to time really the particular message when the local reliable message passing, moreover, if the confirmation is not made within the specified time of validity of the message, no further repetition is not performed, and an indication of an error is passed to the application that relays messages.

12. The method according to claim 9, in which the recurrence interval is governed by the interval delay after successive retry intervals.

13. The method according to claim 8, in which the condition for a channel buffers session state and the Protocol supported in the plug-in repository.

14. The method according to claim 1, in which at least one suitable mechanism for message transport includes at least one of the following transport mechanisms: TCP/IP, UDP, HTTP, RPC and SMTP.

15. The method according to claim 1, wherein the messaging has lots of message exchange patterns containing at least one of: one-way transmission of messages, messaging, request/response and full-duplex transmission of messages.

16. Machine-readable medium that stores executable computer commands that

carry out a method of selecting at least one transport messages to communicate with the application messaging during its execution, and referred to the selecting is performed in the messaging infrastructure at run time, which abstracts the operation of sending and receiving to exchange the messages with the endpoint partner on one or more of the available transport mechanisms messages moreover, the method comprises the steps:

receive one or more commands from the application messaging that define one or more guarantees end-to-end delivery of messages that should be used when selecting at least one suitable mechanism for transporting messages at run time, without determining the application messaging, at least one suitable mechanism for transporting messages during deployment, one or more guarantees end-to-end delivery of the message contains at least one of the following: at least once a message is delivered at most once message delivery, message delivery, order shipment, and the time actually session

choose at least one suitable mechanism for transporting messages from the available mechanisms of transport of messages to meet the requirements of one or more guarantees end-to-end message delivery, specified in one or more commands received from the application messaging, and

create a link within the messaging infrastructure between the application messaging and the selected at least one suitable mechanism for transporting messages to exchange messages between the application messaging and the target point partner.

17. Machine-readable medium according to clause 16, in which the method further comprises the step:

receive one or more commands from the application send messages that indicate one or more properties of the local reliable message transmission, and one or more local reliable message transmission contains at least one of the following: maintaining session state, the validity of the message and transactional buffering messages.

18. A machine-readable medium of 17, in which the session state contains the connect store.

19. A machine-readable medium of 17, in which the properties of a local reliable message transmission additionally contain the maximum buffer quota, which determines the maximum number of messages that must be buffered by the messaging infrastructure, and which, when combined with the maximum message size determines the maximum number of bytes that must be buffered by the messaging infrastructure, a minimum buffer quota, which determines the minimum reserved number of messages that must be buffered by the messaging infrastructure, and which, when combined with the maximum message size determines the minimum number of bytes that must be buffersizeinbytes messaging the timeout when sending, which unlocks the operation of the parcel after the expiry of timeout when sending, and messages with a higher priority have precedence in the transmission and delivery compared to messages with lower priority, and custom property response to message"poisoners", in which the number of times that message delivery is interrupted, is configurable to determine when the message is a "poisoner".

20. Machine-readable medium according to claim 19, in which the timeout when sending authorizes the operation of a parcel only if the buffer quota indicates that the memory area is available, before the expiry of a predefined period of time block.

21. A machine-readable medium of 17, in which the local reliable message sending transactional message buffer is available regardless of the duration of storage of session state.

22. Machine-readable medium according to clause 16, in which the connection includes a channel buffer status of the session, the Protocol and attached storage.

23. Machine-readable medium according to article 22, in which the Protocol copies the received message in the receive buffer.

24. Machine-readable medium according to item 23, in which the Protocol records the sequence number of the next expected message.

25. Machine-readable the media item 23, in which, if the received message is a duplicate of a previously received message, based on the state-supported endpoint session, the duplicate message reject.

26. Machine-readable medium according to article 22, in which one or more specified end-to-end guarantees delivery contain, at least, exactly once delivery of messages, in which the Protocol periodically sends a copy of the previously sent messages to the endpoint of the partner after the expiration of the retry interval until will not be accepted confirmation.

27. Machine-readable media on p, in which one or more specified end-to-end guarantees delivery further comprises a time of validity of the session, and, if confirmation is not made within a specified time, the validity of the session, no further repetition is not performed, and an indication of an error is issued to the application that relays the message.

28. Machine-readable media on p, further comprising stages:

take the property of about time actually messages for local reliable message transfer, and, if confirmation is not made within a specified time, the validity of the message, no further repetition is not performed, and an indication of an error is passed to the application that relays messages.

29. Machine-readable is the l on P16, the method further contains the step:

plan the transfer or delivery at least one message of the sequence of messages to the endpoint of the partner.

30. Machine-readable medium according to clause 29, in which planning is based at least on one of: connectivity, load balancing, message priority, and the use of transport with lower cost.

31. Machine-readable medium according to article 22, in which the state of the channel buffers session state and the Protocol supported in the plug-in repository.

32. The method for selecting at least one transport messages to communicate with the application messaging during its execution, and referred to the selecting is performed in the messaging infrastructure at run time, which abstracts the operation of sending and receiving messaging with end point partner on one or more of the available transport mechanisms messages containing the steps:

determine at run time, at least one suitable transport mechanism, without specifying an application message passing at least one suitable mechanism for transport during deployment, from among the one or more transport mechanisms that satisfy the requirements of one of the second or more guarantees end-to-end delivery, given this app messaging with one or more guarantees end-to-end delivery contains at least one of: at least one-time delivery at the most a single delivery, the delivery order and the time of validity of the session, and

communicate application messaging and certain at least one of a suitable transport mechanism for exchanging messages between the application messaging, and endpoint partner.

33. The method according to p, optionally containing phase to: perform one or more of the properties of the local reliable message transmission, and one or more properties of the local reliable message transmission contains at least one of the following: storing session state, the validity of the message and transactional buffering messages.

34. The method according to p, in which storage of session state is maintained in the plug-in repository, which contains at least one of: store a background process, database storage long-term storage and storage applications.

35. The method according to p in which the property of the local reliable message transmission further comprises: a buffer quota, which determines the maximum number of messages that must be buffered by the transmission infrastructure within the claims, the timeout when sending, which unlocks the operation of the parcel after the expiration of the timeout when sending, the option of priority, in accordance with which a message with a higher priority pass before messages with a lower priority, and property, custom messages-"poisoners", according to which the number of times that message delivery is interrupted, is configurable to determine when the message is a "poisoner".

36. The method according to p in which the property of the local reliable message sending transactional support is available regardless of the duration of storage of session state.

37. The method according to p in which the application messaging and defined, at least one suitable mechanism for transporting the associated channel, the buffer status of the session Protocol and plug storage within the messaging infrastructure.

So on clause 37, in which the channel is an API that provides an abstraction for sending and receiving messages.

39. The method according to § 38, in which the buffers session state contain a buffer of the package and clearly mark the monotonically increasing message sequence number of the message.

40. The method according to § 38, in which the buffers session state contains the receive buffer, which keeps the t messages until they are delivered to the application.

41. The method according to clause 37, in which one or more of these guarantees end-to-end delivery contains at least one message delivery and validity of the message, in which during the time of validity of the message Protocol periodically sends a copy of the previously sent messages to the endpoint of the partner after the expiration of the retry interval, pending a confirmation message.

42. The method according to clause 37, in which the messaging infrastructure provides detection and processing at least one of: a session error or message.

43. The method according to § 42, in which the processing error message contains at least one of: a notification of a running program error, app notification send error notification to one or more plug-in error handlers error, and notification of operator error.

44. The method according to item 43, in which failures survivability contain messages about the damage, lost messages, duplicate messages, reordered messages, failure of transport, network failures, failures of process, system failures.

45. The method according to § 42, in which the messaging infrastructure is notified that an error has been set, and repeats the operation, which was Prieur is Ana error.

46. The method according to clause 37, in which the condition for a channel buffer status of the session and the Protocol supported in the plug-in repository.

47. Machine-readable medium that stores executable computer commands that implement a method of selecting at least one transport messages to communicate with the application messaging during its execution, and referred to the selecting is performed in the messaging infrastructure at run time, which abstracts the operation of sending and receiving messaging with end point partner on one or more of the available transport mechanisms messages, and the method comprises the steps:

determine at run time, at least one suitable transport mechanism, without specifying the application messaging, at least one suitable mechanism for transport during deployment, from among the one or more transport mechanisms that satisfy the one or more end-to-end guarantees of delivery specified by the application messaging, and one or more end-to-end guarantees delivery contains at least one of: at least one-time delivery at the most a single delivery, the delivery order and the time of validity of the session, and

syshestvyut communication application messaging and certain at least one of a suitable transport mechanism for exchanging messages between the application messaging, and endpoint partner.

48. Machine-readable media on p, optionally containing stage to perform one or more of the properties of the local reliable message transmission, and one or more properties of the local reliable message transmission contains at least one of the following: storing session state, the validity of the message and transactional buffering messages.

49. Machine-readable media on p, in which storage of session state is maintained in the plug-in repository, which is at least one of: store a background process, database storage long-term storage and storage applications.

50. Machine-readable media on p, in which the properties of a local reliable message transmission additionally contain: buffer quota, which determines the maximum number of messages that must be buffered by the messaging infrastructure, a timeout when sending, which unlocks the operation of the parcel after the expiration of the timeout when sending, the option of priority, in accordance with which a message with a higher priority pass before messages with a lower priority, and custom property on the message-"poisoners", according to which the number of times that message delivery is interrupted, is configurable to determine when the message is "poisoner".

51. Machine-readable media on p in which the property of the local reliable message transfer on transactional buffering messages available regardless of the duration of storage of session state.

52. Machine-readable media on p in which the application messaging and mentioned certain at least one suitable mechanism for transporting the associated channel, the buffer status of the session Protocol and plug storage within the messaging infrastructure.

53. Machine-readable media according to paragraph 52, in which the buffer status of the session captures the message from the application message transfer, deliver message to the application message transfer and maintains information about the status of sent and received messages.

54. Machine-readable medium according to item 53, in which the status information includes at least one of: a session identifier, one or more specified end-to-end guarantees of transportation and the endpoint address of the partner.

55. Machine-readable medium according to item 53, in which the status information includes at least one of: a sequence number transfer and status verification.

56. Machine-readable medium according to item 53, in which the status information includes at least one of: custom time actually send, blocking lie is and where stored information.

57. Machine-readable media according to paragraph 52, in which the Protocol performs the operation permission endpoints to identify the endpoint of a partner.

58. Machine-readable medium according to § 57, in which the Protocol initializes the operation of the authorization endpoint with an intermediary to route messages to a node in at least one farm applications or section within the application farm.

59. Machine-readable media according to paragraph 52, in which one or more of these guarantees end-to-end delivery contains at least one message delivery and validity of the message, and during the time of validity of the message Protocol periodically sends a copy of the previously sent messages to the endpoint of the partner after the expiration of the retry interval, until will not be accepted confirmation message.

60. Machine-readable media according to paragraph 52, in which the condition for a channel buffers session state and the Protocol supported in the plug-in repository.

61. Machine-readable medium that stores executable computer commands that implement a method of selecting at least one transport messages to communicate with the application messaging during its execution, and mentioned the choice is made for messaging infrastructure during the implementation of the program, which abstracts the storage of session state and operations to send and receive messaging with end point partner on one or more of the available transport mechanisms messages, and the method comprises the steps:

receive one or more commands from the application messaging, which determine the storage of session state and session state is maintained in the plug-in store, containing at least one of: store a background process, database storage long-term storage and the application store, take one or more commands from the application messaging that define one or more guarantees end-to-end delivery, to be used in selecting at least one suitable mechanism for transporting messages at run time, without specifying the application messaging, at least one suitable mechanism for transporting messages in deployment time, with one or more guarantees end-to-end delivery contains at least one of the following: at least once a message is delivered at most once message delivery, message delivery in order parcels, and the time of validity of the session

choose at least one suitable mechanism for transport announced the th of the available transport mechanisms messages to satisfy one or more guarantees end-to-end message delivery specified in the command received from the application messaging, and

create a link within the messaging infrastructure between the application messaging and the selected at least one transport unit for use in the exchange of messages between the application messaging, and endpoint partner.

62. Machine-readable media on p, in which the method further comprises an act of receiving one or more properties of the local reliable message transmission containing at least one of the following:

the reported time actually, transactional buffering messages, the buffer quota, which determines the maximum number of messages that will be buffered by the messaging infrastructure, a timeout when sending, which unlocks the operation of the parcel after expire timeout when sending, the option to prioritize which messages with a higher priority pass before messages with a lower priority, and custom property response to message"poisoners", in which the number of times that message delivery is interrupted, is configurable to determine when the message is "what provide the Etchant".

63. Machine-readable media on p, in which the connection includes a channel buffer status of the session, the Protocol and attached storage.

64. Machine-readable media on p, in which one or more specified end-to-end guarantees delivery contains at least one message delivery and validity of the message, during the time of validity of the message Protocol periodically sends a copy of the previously sent messages to the endpoint of the partner after the expiration of the retry interval, until will not be accepted by the confirmation message.

65. Machine-readable media on p, in which the recurrence interval is governed by the interval delay after successive retry intervals.

66. Machine-readable media on p, in which the method further contains the step of scheduling transmission of at least one message of the sequence of messages to the endpoint of the partner.

67. Machine-readable media on p in which planning is based on at least one of: unstable connectivity, load balancing, message priority, and the use of transport lower cost.

68. Machine-readable media on p, in which the condition for a channel

buffers session state and the Protocol supported in p is glycaemia store.

69. Machine-readable media on p, in which the messaging is defined by many templates message containing at least one of: one-way transmission of messages, the messages are request/response, and full-duplex transmission of messages.



 

Same patents:

FIELD: information technology.

SUBSTANCE: in a wireless LAN, the ACK (acknowledgement signal) transfer rate between AP (access point) and STA (mobile terminal station) there is alternate control based on the number of repeated transmission of snaps of user data. The number of repeatedly transferred snaps is calculated and, if the value is exceeds a predetermined value M, the ACK transfer rate is lowered by one level. The number of successful snaps coming one after the other is calculated and, if the value exceeds a predetermined value N, the transfer rate is raised by one level.

EFFECT: high transfer rate of data in a descending channel does not depend on the ACK transfer rate and the limited frequency band of the wireless network is used effectively.

13 cl, 5 dwg

FIELD: physics, communications.

SUBSTANCE: invention concerns computation resource distribution of network equipment, particularly methods of timing and resource distribution control in data transfer between host and peripheral device. The objective is achieved by sending condition object to each stack level of peripheral device, the object containing condition variables classified as a constant, cashable variable processed by host, or delegated variable processed by peripheral device. Condition to be modified by the network stack and peripheral device is completely divided. E.g., statistic data is tracked by host, device, or host and device. Statistic data tracked by both host and device is divided into non-overlapping parts, which are combined to generate statistic information. At launch initiation, device reaches consistent condition and transfers delegated condition to a stack. Each stack level takes delegated condition and device resources under control when they are free.

EFFECT: transfer of control functions maintaining active network connection to peripheral network device.

28 cl, 8 dwg

FIELD: physics, computing.

SUBSTANCE: invention relates to local area networks. The technical effect is the increase in the local area network quality by generating seven frame types, decrease in the quantity of frame types and overhead costs for the data packet (DP) transmission implementation, and provision of automatic network restoration from a failure/malfunction state when more than one master local area network stations (LNSs) appear in the network or the master LNS disappears from the network, correspondingly. The method of local area network operation with the data communication line with common access and centralised determinated message communication control based on their separation into DPs and the DP transmission in information frames between the addressed subscribers of all its LNSs is implemented using three types of control frames (CF1, CF2, CF3), an information frame (IF), and three types of response frames (RF1, RF2, RF3), CF1 containing the first start combination (SC1), a discriminator field, an individual LNS address field, an addressing modifier (AM), a control command (CC) field, and a monitoring bit; the difference of CF2 from CF1 is the contents of the CC field and the presence of a service word following the CC field; CF3 contains SC1, a discriminator field, an individual DP recipient address field, an individual DP sender address field, a DP length field, an AM, a communication method modifier (CMM), and a monitoring bit, the IF contains the second start combination, a DP field, and a resolvable checksum word, RF1 contains SC1, a discriminator field, an LNS status word, and a monitoring bit, the difference of RF2 from RF1 is the presence of a service word following the LNS status word field, RF3 is CF1 or CF2 or CF3 with inversed values of bits in the discriminator field.

EFFECT: increase in local area network quality, decrease in quantity of frame types and overhead costs for implementation of data packet transmission, and provision of automatic network restoration in event of malfunction.

FIELD: data transmission networks.

SUBSTANCE: in accordance to the invention, value of header or a mark mentioned in given document as identifier of source station (SSID), is added to the header of encapsulated packet, for example, by adding SSID as a mark to the bottom stack of marks of multi-protocol commutation based on mark (MPLS). SSID includes unique identifier, which identifies the network boundary router of provider who is the source of the packet (PE). In certain variants of realization the IP-address of outgoing PE may be used as SSID for that PE. The PE which receives given packet, may then link the MAC-address of Ethernet source for received TLS traffic, for example, to outgoing PE. When an SSID of outgoing PE is available, receiving PE may determine, which commutation route of mark (LSP) should be used for sending Ethernet traffic to station with determined MAC-address.

EFFECT: reduction of marks in the address of the source station.

3 cl, 4 dwg

FIELD: management of traffic channels in radio communication systems.

SUBSTANCE: in accordance to the invention, in a radio-communication system, such as CDMA-system, to load channel, in which two applied systems operate in socket mode in mobile station, is ensured to be capable of transitioning to waiting mode and freeing, when corresponding waiting periods, related to each socket, expire, i.e. when in traffic channel there is no transmission, duration of which exceeds two potentially uneven waiting periods.

EFFECT: putting of traffic channel into waiting mode.

5 cl, 4 dwg

FIELD: multimedia processing systems, in particular, system for multimedia reproduction in a portable device having inbuilt controller.

SUBSTANCE: multimedia system for reproduction of multimedia content in portable data reproduction device contains inbuilt processor for controlling multimedia content reproduction resources, and portable device contains one or more reproduction resource. Multimedia system is made with possible realization of operations for generation of multimedia object on basis of multimedia content, possible association of format processor with multimedia object and possible control of selected reproduction resource with usage of format processor for reproduction of multimedia content from multimedia object.

EFFECT: creation of the system which allows reproduction of new formats of multimedia content on different portable devices without necessity for its adaptation with consideration of different reproduction resources present in each device.

3 cl, 5 dwg

FIELD: computer networks.

SUBSTANCE: invention claims access point device, engineered with possible receipt of data packets from one or more client devices and transmission thereof through network of arbitrary degree of localization, where access point device is made with possible response from the name of network device.

EFFECT: improved control and monitoring of access and network usage.

6 cl, 2 dwg

FIELD: inserting control information about transmission window at radio link control level.

SUBSTANCE: in order to eliminate such drawback as transfer of control information about transmission window only once when determining need for its transfer according to initialization protocol, RLS receiving end periodically finds out if control information about transmission window should be inserted, then it transmits SUFI information about window size once every definite interval, transfers same SUFI information about window size many definite times, and restarts new process upon completion of transfer. Novelty is that sending RLC end can frequently receive SUFI information about window size by periodically inserting SUFI information about window size on RLC receiving end to enhance reliability of transferring SUFI information about window size and to eliminate drawbacks in method for transmitting SUFI information about window size inherent to state of the art. Transmission window size can be adjusted in due time and reduction in effectiveness of using bandwidth for RLC protocol can be eliminated.

EFFECT: provision for eliminating information loss and data transfer control failure.

4 cl, 3 dwg

FIELD: computer telephony, possible use for connecting a regular telephone to personal computer and for telephone conversations using packet telephony.

SUBSTANCE: to ensure uninterrupted connection of a telephone to personal computer, additional electric power is supplied through socket of device for connecting to data transfer network, and also serviceability of telephone connection is ensured independently from condition of operation system of personal computer responsible for operation of office applications.

EFFECT: possible connection of a regular telephone to a personal computer and possible telephone conversations using packet telephony.

2 dwg

FIELD: computing stages based on communication lines, in particular, methods and systems for synchronization of characteristics of communication line width between clients, connected by means of communication line.

SUBSTANCE: in accordance to method, two clients of communication line, ports of which are connected in system with usage of two-point interconnection, exchange characteristics of their capabilities related to support of width of communication line, and width of communication line, which allows mutual synchronization, is synchronized. Interconnection between each pair of clients includes a pair of one-directional communication lines, containing a set of electric wires or tracks, while one track is used by first client for transferring data to second client, and second client uses second track for transferring data to first client.

EFFECT: creation of efficient method and system for synchronization of communication line width characteristics between clients, connected by means of communication line.

6 cl, 8 dwg

FIELD: information technologies.

SUBSTANCE: for assessment of data in data formats incapable of direct assessment, which are transmitted between geodesic instruments, reference catalogues or data catalogues are used. Specified catalogues are preferably transmitted together with transmission of data and assessed data fields are indicated in data formats. If geodesic instrument accepts data format incapable of direct processing, then by means of reference catalogue (10) assessed data fields may be found, and with the help of data catalogue data fields incapable of assessment may be used.

EFFECT: method improvement.

17 cl, 17 dwg

FIELD: computer engineering, namely, local computer networks, in particular, home networks based on universal serial buses.

SUBSTANCE: device for data transmission contains a cable with signal lines, power buses, microchip of computer controller which generates commands which determine operation of peripheral device, microchip of device controller which control directions of streams of data being transmitted, positioned in a peripheral device, two microchips of transformers of signal levels from contacts of control microchips, four circuits for correction of transfer characteristic of signal lines of cable, four matched loads, two stabilizer circuits and four filters meant for reduction of power noise.

EFFECT: removed limitation on length of used cable, possible usage of various types of cables without necessity to develop expensive microchips for repeaters each time, which have functions of double purpose: matching of impedance of cable and controllers and transformation of levels of signals from outputs of controller microchips.

5 dwg

FIELD: technology for transmitting process data from field device to process control center.

SUBSTANCE: in accordance to the invention, process data contains information about working state of field device, and/or information about process variables measured by field device, and/or field device identification data. Process data appearing in time interval between two transmissions is evaluated, divided onto static and dynamic, data is recorded, transferred to process control center. Static data is transferred in abbreviated form, in form of a binary status value.

EFFECT: creation of method for transmitting reduced amount of process data.

2 cl, 2 dwg

FIELD: computer engineering, in particular, electronic computing machines.

SUBSTANCE: the device contains a processor, local address-data multiplexing bus, memorizing device, modernized system controller consisting of a system controller and a block for processing oncoming requests.

EFFECT: prevented hang-up of processors in case of coincidence of oncoming requests from processors, connected to external PCI bus.

2 cl, 1 dwg

FIELD: midget phones or electronic secretaries.

SUBSTANCE: proposed system enables user to pack, transfer, or save dynamic or static information such as video, audio, and scribal information from video display for other user through Internet. Upon receiving information package user can browse all pieces of information contained in mentioned package without addressing various application programs.

EFFECT: facilitated data exchange and message compilation, provision for preventing virus infection through e-mail.

27 cl, 8 dwg

FIELD: systems and method for software control of access between one or more nodes and multiple devices connected thereto.

SUBSTANCE: system has system of parallel used memorizing devices and node, programmed for identification of each memorizing device and masking access from node to at least one memorizing device. System for controlling access to multiple memorizing devices in system of memorizing devices has node, programmed for determining, whether for each of multiple memorizing devices masking should be performed relatively to node and interface for selective modification of programmed data structure. Method describes operation of system for controlling access to multiple parallel use memorizing devices by multiple computers.

EFFECT: possible concurrent transfer of frames in both directions at speed, exceeding 1 Gbit per second, for distance over 10 km.

6 cl, 13 dwg

The invention relates to systems for the transmission of data lines shared tire using a variety of interfaces

The invention relates to computing and information exchange in computer network

The invention relates to a circuit for exchanging signals I / o between the devices to operate in one of multiple modes using a single channel and can be used in electronic measuring Coriolis mass flowmeter

The invention relates to methods of information exchange in computer networks

FIELD: systems and method for software control of access between one or more nodes and multiple devices connected thereto.

SUBSTANCE: system has system of parallel used memorizing devices and node, programmed for identification of each memorizing device and masking access from node to at least one memorizing device. System for controlling access to multiple memorizing devices in system of memorizing devices has node, programmed for determining, whether for each of multiple memorizing devices masking should be performed relatively to node and interface for selective modification of programmed data structure. Method describes operation of system for controlling access to multiple parallel use memorizing devices by multiple computers.

EFFECT: possible concurrent transfer of frames in both directions at speed, exceeding 1 Gbit per second, for distance over 10 km.

6 cl, 13 dwg

Up!