US20050216727A1 - Communication stack for network communication and routing - Google Patents
Communication stack for network communication and routing Download PDFInfo
- Publication number
- US20050216727A1 US20050216727A1 US11/135,933 US13593305A US2005216727A1 US 20050216727 A1 US20050216727 A1 US 20050216727A1 US 13593305 A US13593305 A US 13593305A US 2005216727 A1 US2005216727 A1 US 2005216727A1
- Authority
- US
- United States
- Prior art keywords
- message
- computer
- layer
- reply
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Definitions
- This invention relates generally to computer networks, and more particularly to a communication infrastructure that can be implemented in computers for sending, routing, or receiving network communications.
- the testing of computer networking and application interactions often involve getting one computer with certain testing configuration to interact with another computer with a similar or different testing configuration.
- one computer that supports only Internet Protocol Version 4 may try to communicate with another computer that supports only Internet Protocol Version 6 over a complicated network topology that might include firewalls, multiple domains, etc.
- One major issue for such communications is that the two computers may not even be able to form a connection with each other through regular network links. In other words, the two machines may not have direct network connectivity.
- the computers may be located on two different networks that have not established trust and thus does not allow messages to be routable cross the networks. Also, the two computers may support different transport protocols and thus cannot directly send or receive messages from each other.
- the two machines can form an initial connection, there are other issues that have to be addressed before they can effectively communicate with each other. For instance, if secured communication is required, two machines on disparate networks have to be able to negotiate a security protocol to be used through a third machine that has connectivity to both without trusting the third machine. Also, in some cases one or both computers involved in the network communications may be down or otherwise unable to send or receive messages, and the reliability of the delivery of communication messages will be a concern. For instance, if the two computers communicate to each other as part of a testing operation, and one testing step of one computer is to install an operating system and reboot after the installation, it may not receive messages from the other computer during that period.
- the present invention provides a communication stack infrastructure that enables computers implementing it to send, receive, or route network communications.
- the communication stack includes a message layer, a communication layer, a security layer, and a transport protocol layer.
- the transport layer includes pluggable transport protocol modules that can be selected for sending messages.
- the security layer has pluggable security protocol modules that can be selected for handling security operations.
- the pluggable framework imparts flexibility and extensibility to the communication stack.
- a computer implementing the communication stack can work with other computers implementing the same communication stack to function as a sender, receiver, or router of communication messages.
- an application on an “origin” computer i.e., a computer that initiates a communication connection to the target computer
- the message layer then calls the communication layer to establish the connection for delivering the message through the routing computers between the sending and target computers.
- the communication layer calls the transport layer protocol layer to establish an initial connection with the communication layer with the target computer.
- the communication layer of the origin computer calls the security layer to negotiate security parameters for subsequent communications.
- the communication layer uses the security layer to transmit the payload of the message and to handle subsequent communications.
- FIG. 1 is a block diagram generally illustrating an exemplary computer system on which an embodiment of the communication stack for network communications in accordance with the invention may be implemented;
- FIG. 2 is a schematic diagram showing a plurality of computers located in different networks that may use the communication stack of the invention to send, route, or receive messages;
- FIG. 3 is a schematic diagram showing the architecture of an embodiment of the communication stack of the invention.
- FIG. 4 is a flowchart showing the operation of a message layer in the communication stack.
- FIG. 5 is a schematic diagram showing two computers that communicate through one or more routing computers, with each computer implementing the communication stack of FIG. 3 .
- program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
- program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
- program modules may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like.
- the invention may be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
- program modules may be located in both local and remote memory storage devices.
- FIG. 1 a general purpose computing device is shown in the form of a conventional personal computer 20 , including a processing unit 21 , a system memory 22 , and a system bus 23 that couples various system components including the system memory to the processing unit 21 .
- the system bus 23 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 variety of bus architectures.
- the system memory includes read only memory (ROM) 24 and random access memory (RAM) 25 .
- ROM 24 read only memory
- RAM random access memory
- a basic input/output system (BIOS) 26 containing the basic routines that help to transfer information between elements within the personal computer 20 , such as during start-up, is stored in ROM 24 .
- the personal computer 20 further includes a hard disk drive 27 for reading from and writing to a hard disk 60 , a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29 , and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media.
- the hard disk drive 27 , magnetic disk drive 28 , and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32 , a magnetic disk drive interface 33 , and an optical disk drive interface 34 , respectively.
- the drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20 .
- exemplary environment described herein employs a hard disk 60 , a removable magnetic disk 29 , and a removable optical disk 31 , it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, storage area networks, and the like may also be used in the exemplary operating environment.
- a number of program modules may be stored on the hard disk 60 , magnetic disk 29 , optical disk 31 , ROM 24 or RAM 25 , including an operating system 35 , one or more applications programs 36 , other program modules 37 , and program data 38 .
- a user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and a pointing device 42 .
- Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
- These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB) or a network interface card.
- a monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48 .
- personal computers typically include other peripheral output devices, not shown, such as speakers and printers.
- the personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49 .
- the remote computer 49 may 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 relative to the personal computer 20 , although only a memory storage device 50 has been illustrated in FIG. 1 .
- the logical connections depicted in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52 .
- LAN local area network
- WAN wide area network
- the personal computer 20 When used in a LAN networking environment, the personal computer 20 is connected to the local network 51 through a network interface or adapter 53 . When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over the WAN 52 .
- the modem 54 which may be internal or external, is connected to the system bus 23 via the serial port interface 46 .
- program modules depicted relative to the personal computer 20 may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
- FIG. 2 shows two network domains each having multiple computers.
- a computer 70 on one network in domain A may need to communicate with a computer 72 on another network in domain B. Due to network connectivity issues, however, the computer 70 in domain A may not be able to form a connection with the computer 72 over the network structure using standard network communication means provided by their operating systems.
- the different configurations of the two computers may also make them unable to talk to each other directly.
- the computer 70 may support only TCP as its network transport, while the other computer 72 may only support UDP. Thus, the computer 70 and the computer 72 may be unable to communicate to each other through conventional network links.
- a communication stack 80 is provided to a computer 70 to enable it to send a message to a target computer implementing the same communication stack, and the message may be forwarded through a route with routing computers, such as the computer 76 , that also implement the communication stack.
- each computer may function as a sender, a receiver, or a router between the sender and the receiver. This enables the computer 70 to send communication data through the computer 76 to the target computer 72 to establish a connection, negotiate security parameters, and then send subsequent transmissions via a secured connection, as will be described in greater detail below.
- FIG. 3 shows an embodiment of the communication stack 80 in accordance with the invention.
- the communication stack 80 includes a message layer 90 , a communication layer 92 , a transport protocol layer 94 , a security layer 96 , and a cryptography layer 98 .
- the message layer 90 functions as an interface between an application 100 and the communication layer 92 below it.
- the application 100 can send messages to another application on a target computer, without having to worry about the details of carrying out the message delivery operation.
- the message layer obtains from the application the contents of the message to be sent as well route configuration information regarding the delivery route for the message.
- the configuration information includes data identifying the target machine (or machines) for the message and its port number (corresponding to the application on the target machine that is to receive the message), the route to each target machine, and the security configuration for use in communicating with the target machine.
- the routing information identifies the routing computer for each hop in the route, and the transport protocol used by each routing computer in the route ending at the target machine.
- the security configuration for communicating each target machine indicates in alternative the authentication mechanism to be used, such as Active Directory Authentication or PKI infrastructure.
- the security configuration also indicates if the message has to be delivered encrypted or signed.
- the message layer 90 also stores the message in the case the target machine is not available to establish the connection or receive the message.
- the communications between the machines may be performed for the purpose of carrying out a testing operation that involves the interaction among the machines.
- a target machine may be required to install an operating system as part of the testing sequence. During the installation and the subsequent reboot operation, the target machine will not be able to receive the message from the sending machine. If the message cannot be delivered, the message layer will store it in a message buffer or queue, and try to deliver it at a later time.
- FIG. 4 shows the operation of the message layer in one embodiment of the invention.
- the message layer determines from the message header whether the current machine is the final destination of the message (step 112 ). In an alternative embodiment, this decision is made by the communication layer. If the current machine is not the final destination, the message is delivered to the next server in the route. To that end, a modified message header is created for the next server in the route (step 114 ). The CommOpen API function is then called to use the communication layer to connect to the next server in the route (step 116 ). The CommSend API function is then called to send the message to the next server (step 118 ).
- the message layer checks whether the persistent flag for the message is set (step 120 or 122 ). If so, the message header and payload are persistently stored in a message queue (step 126 of 128 ), and the open and send steps will be repeated later to try to forward the message to the next server.
- the message layer delivers the message to a message handler function registered with the message layer by the target application to receive messages with a given TargetType attribute (step 130 ). If an error occurs in this step, the message header is checked to see whether the persistent flag is set (step 132 ). If so, the message header and the payload are persistently stored in the message queue (step 134 ).
- the transport protocol layer and the security layer preferably use plug-in protocol modules to provide the transport and security functionality.
- the transport layer 94 may have plug-in protocol modules 140 and 142 for TCP and UDP, respectively
- the security layer 96 may have plug-in security protocol modules 144 , 146 , 148 for security operations according to the Active Directory security process, the public key (PKI), or NULL, respectively.
- the NULL security is a dummy security module for machines that does not support security or encryption.
- the message layer 90 puts the message payload and the delivery information in an XML document 150 and passes to the communication layer 92 .
- the communication layer 92 parses the XML input it receives from the message layer and tries to open the connection to the target machine using the correct transport protocol layer implementation.
- the application layer creates a message header with the route configuration information specified therein.
- the routing information in this message header is used by the communication stack to establish a connection all the way to the target machine through the intermediate routers, if any, as specified in the delivery configuration information. This connection is then handed over to the security layer 96 .
- the security layer of the sending machine then negotiates with the security layer of the target machine regarding which security/authentication protocol will be used for security handshake, and then performs the handshake.
- both the target machine and the sending machine will have a symmetric shared key that they will use in the following communication for encryption.
- the message layer 90 and the communication layer 92 are ready to send or receive messages as encrypted or signed buffers. All the subsequent communication happens through the security layer, which encrypts or signs on the sending side as instructed, and decrypts or verifies the signature of the received message on the receiving side.
- This connection between the origin computer and the target computer can be used to send and receive unspecified amount of data in a secured way.
- the cryptographic module 98 is provided to abstract the cryptographic implementation for the communication stack. This module is mainly a helper module.
- the cryptographic functions are provided by cryptography provider dynamic link library (DLL) and exposes a plurality of API functions than can be called by the application 100 , the message layer 90 , the communication layer 92 , or the security layer 96 .
- the cryptographic module 98 is made separate from the other layers so that the communication stack can operate without cryptographic operations on machines that do not support cryptography, such as machines running on a simplified operating system.
- the cryptography module has plug-in modules 152 for using different cryptographic service providers.
- FIG. 5 shows two computers 160 , 162 that communicate through an intermediate routing computer 166 . It will be appreciated, however, that whether a router is used will depend on the locations of the sending and receiving computers, and more than one routing computer may be used for routing messages between the two computers.
- the computer 160 is referred to as the “origin computer” because it is the one that initiates a connection to the computer 162 , which is referred to as the “target computer.”
- the application 164 on the origin computer 160 wants to start sending messages to another application 168 on the target computer 162 , it calls a helper DLL function 170 to identify a route for delivering messages to the target computer.
- the helper DLL consults a database 172 that contains information of all available machines that implement the communication stack and thus can be used for routing.
- the machine information includes their locations and network connectivity, such as the transport protocols supported by each of them, etc.
- the database may be on the local machine of the origin computer, or alternatively may be accessible over a network connection.
- the helper DLL 170 selects machines to form a route that leads to the target machine 162 .
- the route may include no routing machines (i.e., directly from the origin computer to the target computer), or multiple routing machines.
- the helper DLL 172 returns data identifying the route to the application 164 .
- the route data includes data identifying each machine in the route and the transport protocol it supports. In other words, the route data specifies the transport protocol in each stop of the route all the way up to the target computer.
- the application 164 then passes the message to be delivered and the route data to the message layer 176 .
- the message layer then calls the communication layer 178 and gives it the route configuration data to first form a connection with the target computer 162 .
- the message layer 176 and the communication layer 178 pass data in the form of XML documents.
- the communication layer 178 receives the XML document containing the routing configuration for message delivery, it parses the XML lines and generates a connection message 186 to be sent to the target computer 162 for establishing a connection.
- the header 188 of the connection message 186 includes data identifying all the hops from the origin computer to the target computer.
- the communication layer 178 then calls the transport layer 180 to send the connection message 186 .
- the transport protocol layer than uses the plug-in module for the selected transport protocol to send the connection message to the first hop on the route, which in the example of FIG. 5 is the routing computer 166 .
- the routing computer 166 implements the same communication stack of FIG. 3 as the sender and target machines do.
- the computers can communicate in a peer-to-peer fashion, with each of the machines capable of functioning as a sender, a router, or a receiver of messages.
- the routing computer 166 receives the connection message sent by the origin computer, its transport layer 192 passes the message to its communication layer 194 , which in turn passes the message to the message layer 196 .
- the message layer 196 checks the header of the message and sees that the routing computer is not the final destination of the message. In response, it modifies the header to indicate that the message will go to the next computer in the route.
- the communication layer 194 then calls the transport layer 192 to make a connection to the next hop to send the message, and the transport layer forwards the message to the next computer as indicated in the message header.
- the routing computer then keeps forwarding message buffers received from either side to the other side.
- the communication layer 194 rather than the message layer 196 , checks whether the message is for the current machine and, if not, modifies the message header and opens the connection to the next hop on the route. As a result, the message layer 196 is not involved in the routing operation.
- the target computer 162 is the next hop from the routing computer.
- its communication layer 204 receives the connection message, it recognizes that the target computer is the final destination of the message. In response, it returns an acknowledgment message 210 to the origin computer 160 to establish the connection.
- a message handler 212 for the target application 168 is registered with the message layer 206 for receiving subsequent messages from the origin computer.
- the acknowledgment message 210 is sent to the next hop in the route, which is the routing computer 166 .
- the routing computer forwards the acknowledgment message to the origin computer 160 .
- the communication layer 178 of the origin computer 160 calls the security layer 182 to negotiate with the security layer 208 of the target computer 162 regarding the security protocols to be used in subsequent communications between the two machines.
- the two security layers 182 and 208 decide on a symmetric shared secret key that can be used for encrypting/decrypting and authenticating data transmitted between the two.
- the subsequent communications between the two machines will go through the security layers, which performs the required security operations.
- the communication layer 178 calls the security layer 182 to deliver the message payload it received from the message layer 176 (which in turn received message from the application 164 ).
- the security layer 178 encrypts the message using the negotiated key and/or signs the message with the key, and calls the transport layer 180 to send the message 220 through the established route.
- the transport layer 202 of the target computer 162 receives the message, it sends the message to the security layer 208 , which decrypts the message and/or verifies the signature, and then passes the decrypted/authenticated message to the communication layer 204 .
- the communication layer then passes the message to the message layer 206 , which delivers the message to the message handler function registered for the application 168 that is the intended recipient of the message.
- different transport protocols may be used along the route to deliver the message from the origin computer and the target computer.
- the origin computer 160 may support only TCP, while the target computer 162 may support only UDP.
- the two computers can still communicate with each other, however, if the routing computer 166 supports both TCP and UDP.
- the routing computer 166 receives a message from the origin computer 160 via TCP, it converts it to a UCP message and forwards the message to the target computer 162 via UDP.
- the routing computer converts messages from the target computer 162 via UDP to TCP messages and sends them to the origin computer 160 via TCP.
- the application invokes the communication stack by calling appropriate application programming interface (API) functions, and the layers in the communication stack interact with each other also via API functions. Also, data are passed between the application and the layers of the communication stack as XML documents.
- API application programming interface
- MessageHeader schema The schema is defined for the XML documents passed across the layers of the communication stack.
- the Msg APIs are described below. These are the APIs that the applications will implement or call to interact with the message layer and utilize the communication stack.
- MSGHANDLER This is Function Type definition for message handlers. This function type is implemented by the application layer and registered with the message layer. When a message arrived with a matching target type, this function is called by the message layer to deliver the message to the application layer.
- typedef HRESULT (*MSGHANDLER)( IN LPCWSTR cwszHeader, IN DWORD dwPayloadType, IN DWORD dwPayloadSize, IN LPBYTE pbPayload, IN MSGCONTEXT* pMsgContext, OUT LPDWORD pdwReplyType, OUT LPDWORD pdwReplySize, OUT LPBYTE* ppbReply ); Parameters cwszHeader Header in MessageHeader XML format. dwPayloadType
- the payload type can be one of the following: COMM_MSG_TYPE_BINARY
- the payload type is binary data (byte) COMM_MSG_TYPE_XML
- the payload type is XML (WCHAR)
- dwPayloadSize The payload size (bytes).
- pbPayload The payload.
- pMessageContext The message context.
- the reply type can be one of the following: COMM_MSG_TYPE_BINARY
- the reply type is binary data (byte) COMM_MSG_TYPE_XML
- the reply type is XML (WCHAR) pdwReplySize The reply size (bytes). ppbReply The reply.
- STREAMINGFUNCTION This is the function type definition for a streaming function.
- the application layer implements the function and supplies it to the message layer as a way of exchanging an unlimited amount of data between machines.
- This streaming function is used in MsgClientStreamingSendAndReceive( ) function described below.
- typedef HRESULT (*MSGSTREAMINGFUNCTION)( IN MSGCONTEXT* pMsgContext, IN DWORD dwInitDataSize, IN LPBYTE pbInitData, IN DWORD dwInDataSize, IN LPBYTE pbInData, IN DWORD dwOutBufferSize, OUT LPDWORD pdwOutDataSize, OUT LPBYTE* ppbOutData ); Parameters pMsgContext The message context. dwInitDataSize The size of the initialization data. pbInitData The initialization data. dwInDataSize The size of the input data (bytes). pbInData The input data. dwOutputBufferSize The size of the output buffer (bytes). pdwOutputDataSize The size of the output data. ppbOutputData The output data.
- MsgRegisterHandler This function registers the callback function used by a message target to receive messages.
- HRESULT MsgRegisterHandler ( IN DWORD dwFlags, IN LPCWSTR cwszTarget, IN MSGHANDLER MsgHandler, IN DWORD dwMaxNumThreads, IN DWORD dwTimeout, IN SECURITY_DESCRIPTOR* pSecurityDescriptor ); Parameters dwFlags Unused cwszTarget
- the message target The given message handler will be called for all messages delivered to the local machine and the given target.
- four types of agents are defined: XML_MSG_TYPE_SPSRV XML_MSG_TYPE_EA XML_MSG_TYPE_DB XML_MSG_TYPE_FILE MsgHandler
- This callback function will be called for all messages targeted to the given target.
- MsgUnregisterHandler this function unregisters the callback function used by a message target to receive messages.
- HRESULT MsgUnregisterHandler ( IN DWORD dwFlags, IN LPCWSTR cwszTarget, IN MSGHANDLER MsgHandler ); Parameters dwFlags Unused. cwszTarget
- MsgSend this function sends a message to a single target and supports optional store and forward functionality if the message send fails.
- HRESULT MsgSend ( IN DWORD dwFlags, IN LPCWSTR cwszHeader, IN DWORD dwPayloadType, IN DWORD dwPayloadSize, IN LPBYTE pbPayload, OUT HRESULT* phrTarget ); Parameters dwFlags COMM_MSG_FLAGS_PERSIST
- This flag indicates to create a reply header from the wszHeader and to send the reply header instead of wszHeader. This flag can be used to easily reply to the original sender of a message.
- the payload type can be one of the following: COMM_MSG_TYPE_BINARY
- the payload type is binary data (byte) COMM_MSG_TYPE_XML
- the payload type is XML (WCHAR) dwPayloadSize Message payload size (bytes).
- phrTarget Result from message handler. Return Values: Will return S_OK on success else HRESULT failure code.
- Every target that needs to receive a message has to register its own message handler before messages are sent to the target.
- the wszHeader is evaluated to determine where to deliver the message.
- a GUID is generated and used for each new persisted message file name.
- the message header and payload are persisted together in the same message file, which is stored in the Pending directory with the GUID.
- the Message layer maintains a thread that manages sending persisted messages based on the target server, retry interval, and timeout given in the message header. This thread scans the Pending directory every five seconds for new message files. Each new message file found is added to a message file list that is then sorted by message file creation time.
- the message file For each message file list item, the message file is opened to read a small amount of summary information that is stored at the beginning of the file. A message information queue item is then created from this information and added to the end of the appropriate server message information queue. A separate message information queue is created for each server that has one or more associated messages. In this way the original message send order, based on the message file creation time, is preserved on a per-server basis.
- the NextRetryTime for each message is set to MessageCreationTime+RetryInterval, and TimeoutActual is set to MessageCreationTime+Timeout.
- NextRetryTime is synchronized as appropriate to be within RetryInterval CurrentTime.
- NextRetryTime>TimeoutActual If NextRetryTime>TimeoutActual, then the queue item and the associated message file are deleted. If NextRetryTime ⁇ CurrentTime, then the original message file is opened to retrieve the persisted CommSendMessage parameters. Next CommSendMessage is called with the read parameters. If the call succeeds, then the message information queue item and the associated message file are deleted. Otherwise NextRetryTime is set to NextRetryTime+RetryInterval. The server message queues are traversed in this fashion until no currently scheduled messages are found in one pass of the server message queues.
- MsgSendAndReceive This function sends a message to a single target and receives a response.
- HRESULT MsgSendAndReceive ( IN DWORD dwFlags, IN LPCWSTR cwszHeader, IN DWORD dwPayloadType, IN DWORD dwPayloadSize, IN LPBYTE pbPayload, OUT HRESULT* phrTarget, OUT LPDWORD pdwReplyType, OUT LPDWORD pdwReplySize, OUT LPBYTE* ppbReply ); Parameters dwFlags
- NULL terminated string An XML message header that primarily contains routing information. It has forward route information and return route information. Also the security information like, “if the message to be sent encrypted/signed/plain” and “if the reply has to come encrypted/signed/plain” dwPayloadType See the payload type for the MsgSend function. dwPayloadSize Message payload size (bytes). pbPayload Message payload to be delivered. phrTarget Result from message handler. pdwReplyType
- the reply type can be one of the following: COMM_MSG_TYPE_BINARY
- the reply type is binary data (byte) COMM_MSG_TYPE_XML
- the reply type is XML (WCHAR) pdwReplySize Reply size. ppbReply Reply. Return Values
- MsgClientStreamingAndReceive this function is called from the client to negotiate a streaming session with a message handler on the server.
- HRESULT MsgClientStreamingSendAndReceive IN DWORD dwFlags, IN LPCWSTR cwszHeader, IN DWORD dwPayloadType, IN DWORD dwPayloadSize, IN LPBYTE pbPayload, IN DWORD dwStreamingInitDataSize, IN LPBYTE pbStreamingInitData, IN MSGSTREAMINGFUNCTION pStreamingFunction, OUT HRESULT* phrTarget, OUT LPDWORD pdwReplyType, OUT LPDWORD pdwReplySize, OUT LPBYTE* ppbReply ); dwFlags
- NULL terminated string An XML message header that primarily contains routing information. It has forward route information and return route information. Also the security information like, “if the message to be sent encrypted/signed/plain” and “if the reply has to come encrypted/signed/plain” dwPayloadType See the payload type for MsgSend function. dwPayloadSize The payload size (bytes). pbPayload Message payload to be delivered. dwStreamingInitDataSize Size of initialization data (bytes). pbStreamingInitData Initialization data passed into the streaming function. pStreamingFunction
- Streaming function that is called repeatedly as the client receives streaming data from server.
- the size of the reply (bytes).
- MsgReceive this function receives a message.
- HRESULT MsgReceive IN LPCWSTR cwszHeader, DWORD dwPayloadType, DWORD dwPayloadSize, LPBYTE pbPayload, HRESULT* phrTarget, LPDWORD pdwReplyType, LPDWORD pdwReplySize, LPBYTE* ppbReply ); Parameters cwszHeader Header in MessageHeader XML format.
- dwPayloadType See the payload type for the MsgSend function.
- dwPayloadSize The payload size (bytes).
- pbPayload The payload.
- phrTarget The payload.
- pdwReplyType See the reply type for the MsgSendAndReceive function.
- pdwReplySize The reply size (byte
- the communication (Comm) APIs are described below. These APIs implement extended communication services, including routing and security. These APIs rely on the transport layer APIs and communication security APIs to provide basic services.
- CommCreate this function returns a communications handle to use with the Comm APIs.
- the communications handle maintains the state of a connection between calls to the different Comm APIs.
- HRESULT CommCreate IN HCOMM* phComm ); Parameters phComm Pointer to the communications handle. Return Values Will return S_OK on success else HRESULT failure code.
- HRESULT CommOpen ( IN HCOMM hComm, IN LPCWSTR cwszHeader, IN DWORD dwTimeout ); Parameters hComm communications handle. cwszHeader XML string in CommHeader format. dwTimeout Maximum time to wait to open connection to all targets. Return Values Will return S_OK on success else HRESULT failure code.
- connection will fail if the protocol and security (optional) DLLs can not be found or loaded successfully.
- CommSend this function sends the given data via the given communication handle.
- HRESULT CommSend ( IN HCOMM hComm, IN LPCWSTR cwszHeader, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hComm The communications handle.
- cwszHeader XML string in CommHeader format.
- dwTimeout Maximum time to wait for all data to be sent.
- CommReceive this function receives the data via the given communication handle.
- a communication handle is an object that is created while a communication starts (by the CommOpen( ) function) and is used throughout the communication session.
- HRESULT CommReceive IN HCOMM hComm, IN LPDWORD pdwDataSize, IN LPBYTE* ppbData, IN DWORD dwTimeout ); Parameters hComm The communications handle.
- pdwDataSize Pointer to size of data received (bytes).
- ppbData Data received. dwTimeout Maximum time to wait for data to be received.
- CommStartReceive this function creates a thread to accept new connections based on the connection and security information provided in the given message header.
- HRESULT CommStartReceive IN HCOMM hComm, IN LPCWSTR cwszHeader, IN COMMCONNECTIONHANDLER pfHandler, IN LPVOID pvParameter ); Parameters hComm The communication handle. cwszHeader XML string in CommHeader format. pfHandler
- the communication security (CommSec) APIs implement communication services, including authentication, signing, and encryption.
- CommSecCreate this function tries to create a communication security handle returned from the security DLL (the cwszDLL) to be used to obtain security services as specified by the application layer.
- HRESULT CommSecCreate IN LPCWSTR cwszDLL, IN HCOMMSECURITY* phCommSecurity ); Parameters cwszDLL Protocol DLL. phCommSecurity Pointer to the communications security handle.
- CommSecClientInit this method attempts to initialize client security for the given connection.
- HRESULT CommSecClientInit IN HCOMMSECURITY hCommSecurity, IN HCOMMPROTOCOL hCommProtocol, IN LPCWSTR cwszHeader ); Parameters hCommSecurity The communications security handle.
- hCommProtocol The communications protocol handle.
- cwszHeader XML header in CommSecurity format.
- CommSecServerInit this method attempts to initialize server security for the given connection.
- HRESULT CommSecServerInit IN HCOMMSECURITY hCommSecurity, IN HCOMMPROTOCOL hCommProtocol, IN LPCWSTR cwszHeader ); Parameters hCommSecurity The communications security handle.
- hCommProtocol The communications protocol handle.
- cwszHeader XML header in CommSecurity format.
- CommSecSend this method attempts to send data with the given security services before the given timeout.
- HRESULT CommSecSend ( IN HCOMMSECURITY hCommSecurity, IN DWORD dwFlags, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hCommSecurity The communications security handle.
- the communication protocol (CommProtocol) APIs are the lowest level communication APIs. Each communications protocol supported will have its own DLL with an implementation of the APIs specific t that protocol.
- CommProtocolCreate This method attempts to create a protocol handle returned from the given DLL. HRESULT CCommProtocolCreate( IN LPCWSTR cwszDLL, IN HCOMMPROTOCOL* phCommProtocol ); Parameters cwszDLL Protocol DLL. phCommProtocol Pointer to communications protocol handle.
- CommProtocolClientOpen this method attempts to open a connection to a server using the connection information in the given header before the given timeout occurs.
- HRESULT CommProtocolClientOpen ( IN HCOMMPROTOCOL hCommProtocol, IN LPCWSTR cwszHeader, IN DWORD dwTimeout ); Parameters hCommProtocol communications protocol handle. cwszHeader XML header in CommProtocol format. dwTimeout Timeout.
- CommProtocolSend this method attempts to send the given data before the given timeout occurs.
- HRESULT CommProtocolSend ( IN HCOMMPROTOCOL hCommProtocol, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hCommProtocol communications protocol handle.
- dwDataSize Data size.
- pbData Data Data.
- dwTimeout Maximum time to wait to send all data.
- CommProtocolReceive this method attempts to receive the given data before the timeout occurs.
- HRESULT CommProtocolReceive IN HCOMMPROTOCOL hCommProtocol, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hCommProtocol communications protocol handle.
- dwBufferSize Data size.
- pbBuffer Data dwTimeout Maximum time to wait to receive all data.
- CommProtocolServerInit This method attempts to initialize a server connection for accepting client connections with the connection information in the given header.
- HRESULT CommProtocolServerInit IN HCOMMPROTOCOL hCommProtocol, IN LPCWSTR cwszHeader ); Parameters hCommProtocol communications protocol handle. cwszHeader XML header in CommProtocol format.
- CommProtocolServerOpen this method attempts to open a client connection before the given timeout occurs.
- HRESULT CommProtocolServerOpen ( IN HCOMMPROTOCOL hCommProtocol, IN DWORD dwTimeout, OUT HCOMMPROTOCOL* phCommProtocol ); Parameters hCommProtocol Server communications protocol handle. dwTimeout Timeout. phCommProtocol Pointer to client communications protocol handle.
- CommProtocolClose this method attempts to close the connection associated with the given protocol handle.
- HRESULT CommProtocolClose IN HCOMMPROTOCOL hCommProtocol ); Parameters hCommProtocol communications protocol handle.
Abstract
A communication stack enables computers implementing it to send, receive, or route network communications. The communication stack includes a message layer, a communication layer, a security layer, and a transport protocol layer, with plug-in transport protocol modules and plug-in security protocol modules. Each of the origin computer, target computer, and routing computers involved in delivering a message implements the communication stack. An application on the origin computer calls the message layer of the computer to send messages to a target computer and identifies routing computers on the route for delivering the message to the target computer. The message layer calls the communication layer to establish a connection to the target computer. The communication layer uses the transport protocol layer to establish an initial connection with the target computer, and uses the security layer to negotiate security parameters and to handle secured communications between the origin and target computers.
Description
- This invention relates generally to computer networks, and more particularly to a communication infrastructure that can be implemented in computers for sending, routing, or receiving network communications.
- In some networking scenarios, there are needs for computers located in different domains or disparate networks and having different platforms and networking capabilities to talk to one another. For instance, the testing of computer networking and application interactions often involve getting one computer with certain testing configuration to interact with another computer with a similar or different testing configuration. For instance, in a test of distributed client-server interactions, one computer that supports only
Internet Protocol Version 4 may try to communicate with another computer that supports only Internet Protocol Version 6 over a complicated network topology that might include firewalls, multiple domains, etc. One major issue for such communications is that the two computers may not even be able to form a connection with each other through regular network links. In other words, the two machines may not have direct network connectivity. For instance, the computers may be located on two different networks that have not established trust and thus does not allow messages to be routable cross the networks. Also, the two computers may support different transport protocols and thus cannot directly send or receive messages from each other. - Moreover, even if the two machines can form an initial connection, there are other issues that have to be addressed before they can effectively communicate with each other. For instance, if secured communication is required, two machines on disparate networks have to be able to negotiate a security protocol to be used through a third machine that has connectivity to both without trusting the third machine. Also, in some cases one or both computers involved in the network communications may be down or otherwise unable to send or receive messages, and the reliability of the delivery of communication messages will be a concern. For instance, if the two computers communicate to each other as part of a testing operation, and one testing step of one computer is to install an operating system and reboot after the installation, it may not receive messages from the other computer during that period.
- In view of the foregoing, the present invention provides a communication stack infrastructure that enables computers implementing it to send, receive, or route network communications. The communication stack includes a message layer, a communication layer, a security layer, and a transport protocol layer. The transport layer includes pluggable transport protocol modules that can be selected for sending messages. Similarly, the security layer has pluggable security protocol modules that can be selected for handling security operations. The pluggable framework imparts flexibility and extensibility to the communication stack. A computer implementing the communication stack can work with other computers implementing the same communication stack to function as a sender, receiver, or router of communication messages. To send messages to a target computer, an application on an “origin” computer (i.e., a computer that initiates a communication connection to the target computer) calls the message layer of the communication stack on the origin computer and provides information identifying the target computer and the route through which the message is to be sent. The message layer then calls the communication layer to establish the connection for delivering the message through the routing computers between the sending and target computers. The communication layer calls the transport layer protocol layer to establish an initial connection with the communication layer with the target computer. After the initial connection is established, the communication layer of the origin computer calls the security layer to negotiate security parameters for subsequent communications. The communication layer then uses the security layer to transmit the payload of the message and to handle subsequent communications.
-
FIG. 1 is a block diagram generally illustrating an exemplary computer system on which an embodiment of the communication stack for network communications in accordance with the invention may be implemented; -
FIG. 2 is a schematic diagram showing a plurality of computers located in different networks that may use the communication stack of the invention to send, route, or receive messages; -
FIG. 3 is a schematic diagram showing the architecture of an embodiment of the communication stack of the invention; -
FIG. 4 is a flowchart showing the operation of a message layer in the communication stack; and -
FIG. 5 is a schematic diagram showing two computers that communicate through one or more routing computers, with each computer implementing the communication stack ofFIG. 3 . - Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
- The following description begins with a description of a general-purpose computing device that may implement a communication stack for use by applications on different computers to communicate with each other. The communication stack of the invention and its operation in sending, receiving and routing communication messages will be described in greater detail with reference to
FIG. 2-5 . Turning now toFIG. 1 , a general purpose computing device is shown in the form of a conventionalpersonal computer 20, including aprocessing unit 21, asystem memory 22, and asystem bus 23 that couples various system components including the system memory to theprocessing unit 21. Thesystem bus 23 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 variety of bus architectures. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system (BIOS) 26, containing the basic routines that help to transfer information between elements within thepersonal computer 20, such as during start-up, is stored inROM 24. Thepersonal computer 20 further includes ahard disk drive 27 for reading from and writing to ahard disk 60, amagnetic disk drive 28 for reading from or writing to a removablemagnetic disk 29, and anoptical disk drive 30 for reading from or writing to a removableoptical disk 31 such as a CD ROM or other optical media. - The
hard disk drive 27,magnetic disk drive 28, andoptical disk drive 30 are connected to thesystem bus 23 by a harddisk drive interface 32, a magneticdisk drive interface 33, and an opticaldisk drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for thepersonal computer 20. Although the exemplary environment described herein employs ahard disk 60, a removablemagnetic disk 29, and a removableoptical disk 31, it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, storage area networks, and the like may also be used in the exemplary operating environment. - A number of program modules may be stored on the
hard disk 60,magnetic disk 29,optical disk 31,ROM 24 orRAM 25, including anoperating system 35, one ormore applications programs 36,other program modules 37, andprogram data 38. A user may enter commands and information into thepersonal computer 20 through input devices such as akeyboard 40 and apointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to theprocessing unit 21 through aserial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB) or a network interface card. Amonitor 47 or other type of display device is also connected to thesystem bus 23 via an interface, such as avideo adapter 48. In addition to the monitor, personal computers typically include other peripheral output devices, not shown, such as speakers and printers. - The
personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as aremote computer 49. Theremote computer 49 may 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 relative to thepersonal computer 20, although only amemory storage device 50 has been illustrated inFIG. 1 . The logical connections depicted inFIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. - When used in a LAN networking environment, the
personal computer 20 is connected to thelocal network 51 through a network interface oradapter 53. When used in a WAN networking environment, thepersonal computer 20 typically includes amodem 54 or other means for establishing communications over the WAN 52. Themodem 54, which may be internal or external, is connected to thesystem bus 23 via theserial port interface 46. In a networked environment, program modules depicted relative to thepersonal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. - In the description that follows, the invention will be described with reference to acts and symbolic representations of operations that are performed by one or more computers, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operations described hereinafter may also be implemented in hardware.
- Referring now to
FIG. 2 , the present invention is directed to a new communication stack framework that can be used to handle the delivery of network communication messages between computers that may not have direct network connectivity over a conventional network infrastructure. For illustration purposes,FIG. 2 shows two network domains each having multiple computers. Acomputer 70 on one network in domain A may need to communicate with acomputer 72 on another network in domain B. Due to network connectivity issues, however, thecomputer 70 in domain A may not be able to form a connection with thecomputer 72 over the network structure using standard network communication means provided by their operating systems. Also, the different configurations of the two computers may also make them unable to talk to each other directly. For instance, thecomputer 70 may support only TCP as its network transport, while theother computer 72 may only support UDP. Thus, thecomputer 70 and thecomputer 72 may be unable to communicate to each other through conventional network links. - In accordance with the present invention, a
communication stack 80 is provided to acomputer 70 to enable it to send a message to a target computer implementing the same communication stack, and the message may be forwarded through a route with routing computers, such as thecomputer 76, that also implement the communication stack. As will be described in greater detail below, among the computers implementing the communication stack of the invention, each computer may function as a sender, a receiver, or a router between the sender and the receiver. This enables thecomputer 70 to send communication data through thecomputer 76 to thetarget computer 72 to establish a connection, negotiate security parameters, and then send subsequent transmissions via a secured connection, as will be described in greater detail below. -
FIG. 3 shows an embodiment of thecommunication stack 80 in accordance with the invention. As shown inFIG. 3 , thecommunication stack 80 includes amessage layer 90, acommunication layer 92, atransport protocol layer 94, asecurity layer 96, and acryptography layer 98. Generally, themessage layer 90 functions as an interface between anapplication 100 and thecommunication layer 92 below it. By interacting with themessage layer 90, theapplication 100 can send messages to another application on a target computer, without having to worry about the details of carrying out the message delivery operation. The message layer obtains from the application the contents of the message to be sent as well route configuration information regarding the delivery route for the message. In one implementation, the configuration information includes data identifying the target machine (or machines) for the message and its port number (corresponding to the application on the target machine that is to receive the message), the route to each target machine, and the security configuration for use in communicating with the target machine. The routing information identifies the routing computer for each hop in the route, and the transport protocol used by each routing computer in the route ending at the target machine. The security configuration for communicating each target machine indicates in alternative the authentication mechanism to be used, such as Active Directory Authentication or PKI infrastructure. The security configuration also indicates if the message has to be delivered encrypted or signed. - In accordance with an aspect of the invention, the
message layer 90 also stores the message in the case the target machine is not available to establish the connection or receive the message. For instance, in one scenario, the communications between the machines may be performed for the purpose of carrying out a testing operation that involves the interaction among the machines. A target machine may be required to install an operating system as part of the testing sequence. During the installation and the subsequent reboot operation, the target machine will not be able to receive the message from the sending machine. If the message cannot be delivered, the message layer will store it in a message buffer or queue, and try to deliver it at a later time. -
FIG. 4 shows the operation of the message layer in one embodiment of the invention. When the message layer is called through a MsgSend API function (step 110) to deliver a message, the message layer determines from the message header whether the current machine is the final destination of the message (step 112). In an alternative embodiment, this decision is made by the communication layer. If the current machine is not the final destination, the message is delivered to the next server in the route. To that end, a modified message header is created for the next server in the route (step 114). The CommOpen API function is then called to use the communication layer to connect to the next server in the route (step 116). The CommSend API function is then called to send the message to the next server (step 118). If the call to either the CommOpen function or the CommSend function returns an error, the message layer checks whether the persistent flag for the message is set (step 120 or 122). If so, the message header and payload are persistently stored in a message queue (step 126 of 128), and the open and send steps will be repeated later to try to forward the message to the next server. - If, on the other hand, it is determined that the current machine is the final destination of the message (step 112), the message layer delivers the message to a message handler function registered with the message layer by the target application to receive messages with a given TargetType attribute (step 130). If an error occurs in this step, the message header is checked to see whether the persistent flag is set (step 132). If so, the message header and the payload are persistently stored in the message queue (step 134).
- Returning to
FIG. 3 , in accordance with another aspect of the invention, the transport protocol layer and the security layer preferably use plug-in protocol modules to provide the transport and security functionality. For instance, as shown inFIG. 3 , thetransport layer 94 may have plug-inprotocol modules security layer 96 may have plug-insecurity protocol modules - In a preferred embodiment, the
message layer 90 puts the message payload and the delivery information in anXML document 150 and passes to thecommunication layer 92. Thecommunication layer 92 parses the XML input it receives from the message layer and tries to open the connection to the target machine using the correct transport protocol layer implementation. To that end, the application layer creates a message header with the route configuration information specified therein. The routing information in this message header is used by the communication stack to establish a connection all the way to the target machine through the intermediate routers, if any, as specified in the delivery configuration information. This connection is then handed over to thesecurity layer 96. - The security layer of the sending machine then negotiates with the security layer of the target machine regarding which security/authentication protocol will be used for security handshake, and then performs the handshake. In one preferred embodiment, at the end of the security handshake, both the target machine and the sending machine will have a symmetric shared key that they will use in the following communication for encryption. Now the
message layer 90 and thecommunication layer 92 are ready to send or receive messages as encrypted or signed buffers. All the subsequent communication happens through the security layer, which encrypts or signs on the sending side as instructed, and decrypts or verifies the signature of the received message on the receiving side. This connection between the origin computer and the target computer can be used to send and receive unspecified amount of data in a secured way. - The
cryptographic module 98 is provided to abstract the cryptographic implementation for the communication stack. This module is mainly a helper module. In one implementation, the cryptographic functions are provided by cryptography provider dynamic link library (DLL) and exposes a plurality of API functions than can be called by theapplication 100, themessage layer 90, thecommunication layer 92, or thesecurity layer 96. Thecryptographic module 98 is made separate from the other layers so that the communication stack can operate without cryptographic operations on machines that do not support cryptography, such as machines running on a simplified operating system. In a preferred embodiment, the cryptography module has plug-inmodules 152 for using different cryptographic service providers. - To illustrate the process of utilizing the communication stack to establish connections and routing messages,
FIG. 5 shows twocomputers intermediate routing computer 166. It will be appreciated, however, that whether a router is used will depend on the locations of the sending and receiving computers, and more than one routing computer may be used for routing messages between the two computers. - In the example of
FIG. 5 , thecomputer 160 is referred to as the “origin computer” because it is the one that initiates a connection to thecomputer 162, which is referred to as the “target computer.” When theapplication 164 on theorigin computer 160 wants to start sending messages to anotherapplication 168 on thetarget computer 162, it calls ahelper DLL function 170 to identify a route for delivering messages to the target computer. The helper DLL consults adatabase 172 that contains information of all available machines that implement the communication stack and thus can be used for routing. The machine information includes their locations and network connectivity, such as the transport protocols supported by each of them, etc. The database may be on the local machine of the origin computer, or alternatively may be accessible over a network connection. Thehelper DLL 170 selects machines to form a route that leads to thetarget machine 162. As mentioned above, the route may include no routing machines (i.e., directly from the origin computer to the target computer), or multiple routing machines. After the route is selected, thehelper DLL 172 returns data identifying the route to theapplication 164. In one embodiment, the route data includes data identifying each machine in the route and the transport protocol it supports. In other words, the route data specifies the transport protocol in each stop of the route all the way up to the target computer. - The
application 164 then passes the message to be delivered and the route data to themessage layer 176. The message layer then calls thecommunication layer 178 and gives it the route configuration data to first form a connection with thetarget computer 162. As mentioned above, in a preferred embodiment, themessage layer 176 and thecommunication layer 178 pass data in the form of XML documents. After thecommunication layer 178 receives the XML document containing the routing configuration for message delivery, it parses the XML lines and generates aconnection message 186 to be sent to thetarget computer 162 for establishing a connection. Theheader 188 of theconnection message 186 includes data identifying all the hops from the origin computer to the target computer. Thecommunication layer 178 then calls thetransport layer 180 to send theconnection message 186. The transport protocol layer than uses the plug-in module for the selected transport protocol to send the connection message to the first hop on the route, which in the example ofFIG. 5 is therouting computer 166. - As shown in
FIG. 5 , therouting computer 166 implements the same communication stack ofFIG. 3 as the sender and target machines do. By implementing the same communication stack, the computers can communicate in a peer-to-peer fashion, with each of the machines capable of functioning as a sender, a router, or a receiver of messages. When therouting computer 166 receives the connection message sent by the origin computer, itstransport layer 192 passes the message to itscommunication layer 194, which in turn passes the message to themessage layer 196. Themessage layer 196 checks the header of the message and sees that the routing computer is not the final destination of the message. In response, it modifies the header to indicate that the message will go to the next computer in the route. Thecommunication layer 194 then calls thetransport layer 192 to make a connection to the next hop to send the message, and the transport layer forwards the message to the next computer as indicated in the message header. The routing computer then keeps forwarding message buffers received from either side to the other side. In an alternative embodiment, thecommunication layer 194, rather than themessage layer 196, checks whether the message is for the current machine and, if not, modifies the message header and opens the connection to the next hop on the route. As a result, themessage layer 196 is not involved in the routing operation. - In the example of
FIG. 5 , thetarget computer 162 is the next hop from the routing computer. When itscommunication layer 204 receives the connection message, it recognizes that the target computer is the final destination of the message. In response, it returns anacknowledgment message 210 to theorigin computer 160 to establish the connection. Also, amessage handler 212 for thetarget application 168 is registered with themessage layer 206 for receiving subsequent messages from the origin computer. Theacknowledgment message 210 is sent to the next hop in the route, which is therouting computer 166. The routing computer forwards the acknowledgment message to theorigin computer 160. When thecommunication layer 178 of theorigin computer 160 receives the response message from the target computer, it calls thesecurity layer 182 to negotiate with thesecurity layer 208 of thetarget computer 162 regarding the security protocols to be used in subsequent communications between the two machines. As the result of the security negotiation, the twosecurity layers communication layer 178 calls thesecurity layer 182 to deliver the message payload it received from the message layer 176 (which in turn received message from the application 164). Thesecurity layer 178 encrypts the message using the negotiated key and/or signs the message with the key, and calls thetransport layer 180 to send themessage 220 through the established route. When thetransport layer 202 of thetarget computer 162 receives the message, it sends the message to thesecurity layer 208, which decrypts the message and/or verifies the signature, and then passes the decrypted/authenticated message to thecommunication layer 204. The communication layer then passes the message to themessage layer 206, which delivers the message to the message handler function registered for theapplication 168 that is the intended recipient of the message. - In accordance with an aspect of the invention, different transport protocols may be used along the route to deliver the message from the origin computer and the target computer. By way of example, in the message delivery illustrated in
FIG. 5 , theorigin computer 160 may support only TCP, while thetarget computer 162 may support only UDP. The two computers can still communicate with each other, however, if therouting computer 166 supports both TCP and UDP. When therouting computer 166 receives a message from theorigin computer 160 via TCP, it converts it to a UCP message and forwards the message to thetarget computer 162 via UDP. In the reverse direction, the routing computer converts messages from thetarget computer 162 via UDP to TCP messages and sends them to theorigin computer 160 via TCP. - Returning to
FIG. 3 , in a preferred embodiment, the application invokes the communication stack by calling appropriate application programming interface (API) functions, and the layers in the communication stack interact with each other also via API functions. Also, data are passed between the application and the layers of the communication stack as XML documents. The schema for data passing and the API functions provided in one implementation will be described in detail below. It will be appreciated that the concept and embodiments of the invention are not restricted to any particular applications and can be used to enable any two or more machines to communicate in a secured fashion. - MessageHeader schema: The schema is defined for the XML documents passed across the layers of the communication stack.
-
- 1. MessageHeader: (required) (1)
- a. These elements and attributes define message handling and delivery characteristics.
- b. Message: (required) (1)
- i. These attributes specify how to handle delivering a message.
- ii. ID: (required) (generated)
- 1. The ID is a generated GUID that is unique to each message.
- iii. Target: (required)
- 1. The Target identifies the message handler on the server to deliver the message to (see MsgRegisterHandler).
- iv. Class: (optional)
- 1. The Class is an attribute that the client and/or server can define and use for what purposes they require.
- v. UserID: (optional)
- 1. The UserID is defined by the client. If this ID is specified in a message that is persisted, then any existing message with the same ID will be overwritten.
- vi. RetryInterval: (optional)
- 1. If a message is persisted, then the RetryInterval specifies how often to retry sending the persisted message.
- vii. Timeout: (required)
- 1. The Timeout specifies how long to wait for a message to be delivered and a reply received before the request times out and an error occurs.
- c. Reply: (optional) (1)
- i. These attributes are the same as the Message attributes, and they specify how to handle delivering a reply message. The Reply can be used by a client to specify where a message handler should send a reply message. The Reply in the reply message would contain the Message from the original message.
- d. CommHeader: (required) (1)
- See below.
- 1. MessageHeader: (required) (1)
- CommHeader schema:
-
- 1. CommHeader: (required) (1)
- a. These elements and attributes define connection specific characteristics. Eventually multiple connections and/or connections using one or more intermediate connections may be implemented.
- b. Connection: (required) (1+)
- i. CommProtocol: (required) (1)
- 1. See below.
- ii. CommSecurity: (optional) (1)
- 1. See below.
- iii. Connection: (optional) (0+)
- 1. This is a subconnection that specifies that the parent connection is an intermediate connection. Connection(s) or subconnection(s) that have no subconnections themselves represent the final target connection(s).
- i. CommProtocol: (required) (1)
- c. ReplyRoute: (optional) (1)
- i. The ReplyRoute can be used to define a route that the message handler should use to send a reply.
- 1. CommHeader: (required) (1)
- CommProtocol schema:
-
- 1. CommProtocol: (required) (1)
- a. These attributes define the required protocol-specific characteristics.
- b. DLL: (required) (1)
- i. The protocol implementation DLL.
- c. <others>: (?)
- i. Additional attributes defined by the specific protocol.
- 1. CommProtocol: (required) (1)
- CommSecurity schema:
-
- 1. CommSecurity: (required) (1)
- a. These attributes define the required protocol-specific characteristics.
- b. DLL: (required)
- i. The protocol implementation DLL.
- c. Flags: (required)
- i. Security flags (COMMSECURITY_FLAGS_*).
- d. <others>: (?)
- 1. CommSecurity: (required) (1)
- The following are examples of XML contents based on the schema above.
Direct connection (SERVER): <?xml version=“1.0”?> <MessageHeader> <Message ID=“(generated)“ Target=“EA“ Class=“TaskUpdate“ UserID=“EA<N>TaskUpdateID“ RetryInterval=“15“ Timeout=“60“/> <Reply ID=“(original message ID)“ Target=“ EA.Error“ Class=“TaskUpdateError“ UserID=“EA<N>TaskUpdateID“ RetryInterval=“15“ Timeout=“60“/> <CommHeader> <Connection> <CommProtocol DLL=“CommTCPIP“ ServerName=”SERVER” Port=”12345” IPVersion=”4”/> <CommSecurity DLL=“CommSecurityPKI“ Flags=″3″ PublicKey =”XKY0R321DSFE53”/> </Connection> </CommHeader> </MessageHeader> - Multiple connection (SERVER1 and SERVER2):
<?xmlversion=“1.0”?> <MessageHeader> <Message ID=“(generated)“ Target=“EA“ Class=“TaskUpdate“ UserID=“EA<N>TaskUpdateID“ RetryInterval=“15“ Timeout=“60“/> <Reply ID=“(original message ID)“ Target=“EA.Error“ Class=“TaskUpdateError“ UserID=“EA<N>TaskUpdateID“ RetryInterval=“15“ Timeout=“60“/> <CommHeader> <Connection> <CommProtocol DLL=“CommTCPIP“ ServerName=”SERVER1” Port=”12345” IPVersion=”4”/> <CommSecurity DLL=“CommSecurityPKI“ Flags=″3″ PublicKey = ”XKY0R321DSFE53 SERVER1”/> </Connection> <Connection> <CommProtocol DLL=“CommTCPIP“ ServerName=”SERVER2” Port=”12345” IPVersion=”4”/> <CommSecurity DLL=“CommSecurityPKI“ Flags=″3″ PublicKey =”XKY0R321DSFE53 SERVER2”/> </Connection> </CommHeader> </MessageHeader> - Intermediate connection (SERVER2 via SERVER1):
<?xml version=“1.0”?> <MessageHeader> <Message ID=“(generated)“ Target=“EA“ Class=“TaskUpdate“ UserID=“EA<N>TaskUpdateID“ RetryInterval=“15“ Timeout=“60“/> <Reply ID=“(original message ID)“ Target=“EA.Error“ Class=“TaskUpdateError“ UserID=“EA<N>TaskUpdateID“ RetryInterval=“15“ Timeout=“60“/> <CommHeader> <Connection> <CommProtocol DLL=“CommTCPIP“ ServerName=”SERVER1” Port=”12345” IPVersion=”4”/> <Connection> <CommProtocol DLL=“CommTCPIP“ ServerName=”SERVER2” Port=”12345” IPVersion=”4”/> <CommSecurity DLL=“CommSecurityPKI“ Flags=″3″ PublicKey =”XKY0R321DSFE53”/> </Connection> </Connection> </CommHeader> </MessageHeader> - The Msg APIs are described below. These are the APIs that the applications will implement or call to interact with the message layer and utilize the communication stack.
- MSGHANDLER: This is Function Type definition for message handlers. This function type is implemented by the application layer and registered with the message layer. When a message arrived with a matching target type, this function is called by the message layer to deliver the message to the application layer.
typedef HRESULT (*MSGHANDLER)( IN LPCWSTR cwszHeader, IN DWORD dwPayloadType, IN DWORD dwPayloadSize, IN LPBYTE pbPayload, IN MSGCONTEXT* pMsgContext, OUT LPDWORD pdwReplyType, OUT LPDWORD pdwReplySize, OUT LPBYTE* ppbReply ); Parameters cwszHeader Header in MessageHeader XML format. dwPayloadType - The payload type can be one of the following:
COMM_MSG_TYPE_BINARY The payload type is binary data (byte) COMM_MSG_TYPE_XML The payload type is XML (WCHAR) dwPayloadSize The payload size (bytes). pbPayload The payload. pMessageContext The message context. pdwReplyType - The reply type can be one of the following:
COMM_MSG_TYPE_BINARY The reply type is binary data (byte) COMM_MSG_TYPE_XML The reply type is XML (WCHAR) pdwReplySize The reply size (bytes). ppbReply The reply. - STREAMINGFUNCTION: This is the function type definition for a streaming function. The application layer implements the function and supplies it to the message layer as a way of exchanging an unlimited amount of data between machines. This streaming function is used in MsgClientStreamingSendAndReceive( ) function described below.
typedef HRESULT (*MSGSTREAMINGFUNCTION)( IN MSGCONTEXT* pMsgContext, IN DWORD dwInitDataSize, IN LPBYTE pbInitData, IN DWORD dwInDataSize, IN LPBYTE pbInData, IN DWORD dwOutBufferSize, OUT LPDWORD pdwOutDataSize, OUT LPBYTE* ppbOutData ); Parameters pMsgContext The message context. dwInitDataSize The size of the initialization data. pbInitData The initialization data. dwInDataSize The size of the input data (bytes). pbInData The input data. dwOutputBufferSize The size of the output buffer (bytes). pdwOutputDataSize The size of the output data. ppbOutputData The output data. - MsgRegisterHandler: This function registers the callback function used by a message target to receive messages.
HRESULT MsgRegisterHandler( IN DWORD dwFlags, IN LPCWSTR cwszTarget, IN MSGHANDLER MsgHandler, IN DWORD dwMaxNumThreads, IN DWORD dwTimeout, IN SECURITY_DESCRIPTOR* pSecurityDescriptor ); Parameters dwFlags Unused cwszTarget - The message target. The given message handler will be called for all messages delivered to the local machine and the given target. Currently four types of agents are defined:
XML_MSG_TYPE_SPSRV XML_MSG_TYPE_EA XML_MSG_TYPE_DB XML_MSG_TYPE_FILE MsgHandler - This callback function will be called for all messages targeted to the given target.
-
- dwMaxNumThreads
- The maximum number of threads allowed to call the function.
-
- dwTimeout
- The maximum time to wait to call the function.
-
- pSecurityDescriptor
- Security descriptor.
- Remarks
- Only one callback function can be registered for each message agent.
- MsgUnregisterHandler: this function unregisters the callback function used by a message target to receive messages.
HRESULT MsgUnregisterHandler( IN DWORD dwFlags, IN LPCWSTR cwszTarget, IN MSGHANDLER MsgHandler ); Parameters dwFlags Unused. cwszTarget - The message target that was previously registered.
-
- MsgHandler
- The function that was previously registered.
- MsgSend: this function sends a message to a single target and supports optional store and forward functionality if the message send fails.
HRESULT MsgSend( IN DWORD dwFlags, IN LPCWSTR cwszHeader, IN DWORD dwPayloadType, IN DWORD dwPayloadSize, IN LPBYTE pbPayload, OUT HRESULT* phrTarget ); Parameters dwFlags COMM_MSG_FLAGS_PERSIST - If this flag is specified, then the payload is immediately written to the pending directory to be sent later. This flag overrides
-
- COMM_FLAGS_PERSISTONERROR.
- COMM_MSG_FLAGS_PERSISTONERROR
- If this flag is specified, then an attempt is made to immediately deliver the message. If an error occurs, then the payload is immediately written to the pending directory.
-
- COMM_MSG_FLAGS_LOCALPERSISTONLY
- If this flag is specified, then the below flags are removed before the message is delivered to another server:
-
- COMM_FLAGS_PERSIST
- COMM_FLAGS_PERSISTONERROR
- COMM_MSG_FLAGS_PERSISTED
- This flag is removed before the message is delivered to another server. If this flag is specified, then the below flags are ignored:
-
- COMM_FLAGS_PERSIST
- COMM_FLAGS_PERSISTONERROR
- COMM_MSG_FLAGS_CREATEREPLYHEADER
- This flag indicates to create a reply header from the wszHeader and to send the reply header instead of wszHeader. This flag can be used to easily reply to the original sender of a message.
-
- cwszHeader
- XML string in MessageHeader format.
-
- dwPayloadType
- The payload type can be one of the following:
COMM_MSG_TYPE_BINARY The payload type is binary data (byte) COMM_MSG_TYPE_XML The payload type is XML (WCHAR) dwPayloadSize Message payload size (bytes). pbPayload Message payload to be delivered. phrTarget Result from message handler.
Return Values: Will return S_OK on success else HRESULT failure code. - Regarding the MsgSend API function, every target that needs to receive a message has to register its own message handler before messages are sent to the target. The wszHeader is evaluated to determine where to deliver the message. A GUID is generated and used for each new persisted message file name. The message header and payload are persisted together in the same message file, which is stored in the Pending directory with the GUID. The Message layer maintains a thread that manages sending persisted messages based on the target server, retry interval, and timeout given in the message header. This thread scans the Pending directory every five seconds for new message files. Each new message file found is added to a message file list that is then sorted by message file creation time. For each message file list item, the message file is opened to read a small amount of summary information that is stored at the beginning of the file. A message information queue item is then created from this information and added to the end of the appropriate server message information queue. A separate message information queue is created for each server that has one or more associated messages. In this way the original message send order, based on the message file creation time, is preserved on a per-server basis. The NextRetryTime for each message is set to MessageCreationTime+RetryInterval, and TimeoutActual is set to MessageCreationTime+Timeout. For the first queue item in each server message queue, NextRetryTime is synchronized as appropriate to be within RetryInterval CurrentTime. If NextRetryTime>TimeoutActual, then the queue item and the associated message file are deleted. If NextRetryTime<CurrentTime, then the original message file is opened to retrieve the persisted CommSendMessage parameters. Next CommSendMessage is called with the read parameters. If the call succeeds, then the message information queue item and the associated message file are deleted. Otherwise NextRetryTime is set to NextRetryTime+RetryInterval. The server message queues are traversed in this fashion until no currently scheduled messages are found in one pass of the server message queues.
- MsgSendAndReceive: This function sends a message to a single target and receives a response.
HRESULT MsgSendAndReceive( IN DWORD dwFlags, IN LPCWSTR cwszHeader, IN DWORD dwPayloadType, IN DWORD dwPayloadSize, IN LPBYTE pbPayload, OUT HRESULT* phrTarget, OUT LPDWORD pdwReplyType, OUT LPDWORD pdwReplySize, OUT LPBYTE* ppbReply ); Parameters dwFlags - See the values and their meaning for dwFlags in the MsgSend function.
-
- cwszHeader
- NULL terminated string. An XML message header that primarily contains routing information. It has forward route information and return route information. Also the security information like, “if the message to be sent encrypted/signed/plain” and “if the reply has to come encrypted/signed/plain”
dwPayloadType See the payload type for the MsgSend function. dwPayloadSize Message payload size (bytes). pbPayload Message payload to be delivered. phrTarget Result from message handler. pdwReplyType - The reply type can be one of the following:
COMM_MSG_TYPE_BINARY The reply type is binary data (byte) COMM_MSG_TYPE_XML The reply type is XML (WCHAR) pdwReplySize Reply size. ppbReply Reply. Return Values - Will return S_OK on success else HRESULT failure code.
- MsgClientStreamingAndReceive: this function is called from the client to negotiate a streaming session with a message handler on the server.
HRESULT MsgClientStreamingSendAndReceive( IN DWORD dwFlags, IN LPCWSTR cwszHeader, IN DWORD dwPayloadType, IN DWORD dwPayloadSize, IN LPBYTE pbPayload, IN DWORD dwStreamingInitDataSize, IN LPBYTE pbStreamingInitData, IN MSGSTREAMINGFUNCTION pStreamingFunction, OUT HRESULT* phrTarget, OUT LPDWORD pdwReplyType, OUT LPDWORD pdwReplySize, OUT LPBYTE* ppbReply ); dwFlags - See the values and their meanings for dwflagsfor the MsgSend function.
-
- wszHeader
- NULL terminated string. An XML message header that primarily contains routing information. It has forward route information and return route information. Also the security information like, “if the message to be sent encrypted/signed/plain” and “if the reply has to come encrypted/signed/plain”
dwPayloadType See the payload type for MsgSend function. dwPayloadSize The payload size (bytes). pbPayload Message payload to be delivered. dwStreamingInitDataSize Size of initialization data (bytes). pbStreamingInitData Initialization data passed into the streaming function. pStreamingFunction - Streaming function that is called repeatedly as the client receives streaming data from server.
-
- phrTarget
- The value returned by the message handler.
-
- pdwReplyType
- See the reply type for the MsgSendAndReceive function.
- The reply type pdwReplySize
- pdwReplyType
- The size of the reply (bytes).
-
- ppbReply
- Message reply.
- Return Values
- Will return S_OK on success else HRESULT failure code.
- MsgReceive: this function receives a message.
HRESULT MsgReceive( IN LPCWSTR cwszHeader, DWORD dwPayloadType, DWORD dwPayloadSize, LPBYTE pbPayload, HRESULT* phrTarget, LPDWORD pdwReplyType, LPDWORD pdwReplySize, LPBYTE* ppbReply ); Parameters cwszHeader Header in MessageHeader XML format. dwPayloadType See the payload type for the MsgSend function. dwPayloadSize The payload size (bytes). pbPayload The payload. phrTarget The payload. pdwReplyType See the reply type for the MsgSendAndReceive function. pdwReplySize The reply size (bytes). ppbReply The reply. - The communication (Comm) APIs are described below. These APIs implement extended communication services, including routing and security. These APIs rely on the transport layer APIs and communication security APIs to provide basic services.
- CommCreate: this function returns a communications handle to use with the Comm APIs. The communications handle maintains the state of a connection between calls to the different Comm APIs.
HRESULT CommCreate( IN HCOMM* phComm ); Parameters phComm Pointer to the communications handle. Return Values Will return S_OK on success else HRESULT failure code. - CommOpen: this function opens a connection using the connection an security information provided in the given message header.
HRESULT CommOpen( IN HCOMM hComm, IN LPCWSTR cwszHeader, IN DWORD dwTimeout ); Parameters hComm communications handle. cwszHeader XML string in CommHeader format. dwTimeout Maximum time to wait to open connection to all targets. Return Values Will return S_OK on success else HRESULT failure code. Remarks - The connection will fail if the protocol and security (optional) DLLs can not be found or loaded successfully.
- CommSend: this function sends the given data via the given communication handle.
HRESULT CommSend( IN HCOMM hComm, IN LPCWSTR cwszHeader, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hComm The communications handle. cwszHeader XML string in CommHeader format. dwDataSize Size of data to be sent (bytes). pbData Data to be sent. dwTimeout Maximum time to wait for all data to be sent. - CommReceive: this function receives the data via the given communication handle. A communication handle is an object that is created while a communication starts (by the CommOpen( ) function) and is used throughout the communication session.
HRESULT CommReceive( IN HCOMM hComm, IN LPDWORD pdwDataSize, IN LPBYTE* ppbData, IN DWORD dwTimeout ); Parameters hComm The communications handle. pdwDataSize Pointer to size of data received (bytes). ppbData Data received. dwTimeout Maximum time to wait for data to be received. - CommClose: this function closes the given communications handle.
HRESULT CommClose( IN HCOMM hComm ); Parameters hComm The communications handle. - CommStartReceive: this function creates a thread to accept new connections based on the connection and security information provided in the given message header.
HRESULT CommStartReceive( IN HCOMM hComm, IN LPCWSTR cwszHeader, IN COMMCONNECTIONHANDLER pfHandler, IN LPVOID pvParameter ); Parameters hComm The communication handle. cwszHeader XML string in CommHeader format. pfHandler - Function to call after accepting a new connection. This function will be passed the new connection handle and pvParameter.
-
- pvParameter
- Handler context parameter.
- CommEndReceive: this function ends the connection server thread previously created.
HRESULT CommEndReceive( IN HCOMM hComm, IN DWORD dwTimeout ); Parameters hComm The communication handle. dwTimeout Maximum time to wait for the connection server thread to end. - CommDelete: this function deletes the communications handle.
HRESULT CommDelete( IN HCOMM hComm ); Parameters hComm Communication handle. - The communication security (CommSec) APIs implement communication services, including authentication, signing, and encryption.
- CommSecCreate: this function tries to create a communication security handle returned from the security DLL (the cwszDLL) to be used to obtain security services as specified by the application layer.
HRESULT CommSecCreate( IN LPCWSTR cwszDLL, IN HCOMMSECURITY* phCommSecurity ); Parameters cwszDLL Protocol DLL. phCommSecurity Pointer to the communications security handle. - CommSecClientInit: this method attempts to initialize client security for the given connection.
HRESULT CommSecClientInit( IN HCOMMSECURITY hCommSecurity, IN HCOMMPROTOCOL hCommProtocol, IN LPCWSTR cwszHeader ); Parameters hCommSecurity The communications security handle. hCommProtocol The communications protocol handle. cwszHeader XML header in CommSecurity format. - CommSecServerInit: this method attempts to initialize server security for the given connection.
HRESULT CommSecServerInit( IN HCOMMSECURITY hCommSecurity, IN HCOMMPROTOCOL hCommProtocol, IN LPCWSTR cwszHeader ); Parameters hCommSecurity The communications security handle. hCommProtocol The communications protocol handle. cwszHeader XML header in CommSecurity format. - CommSecSend: this method attempts to send data with the given security services before the given timeout.
HRESULT CommSecSend( IN HCOMMSECURITY hCommSecurity, IN DWORD dwFlags, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hCommSecurity The communications security handle. dwFlags Security service flags (COMMSECURITY_FLAGS_*). dwDataSize Data size. pbData Data. dwTimeout Timeout. - CommSecReceive: this method attempts to receive data before the given timeout.
HRESULT CommSecReceive( IN HCOMMSECURITY hCommSecurity, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hCommSecurity communications security handle. dwDataSize Data size. pbData Data. dwTimeout Timeout. - CommSecDelete: this method deletes the given communications handle.
HRESULT CommSecDelete( IN HCOMMSECURITY hCommSecurity ); Parameters hCommSecurity communications security handle. - The communication protocol (CommProtocol) APIs are the lowest level communication APIs. Each communications protocol supported will have its own DLL with an implementation of the APIs specific t that protocol.
- CommProtocolCreate: This method attempts to create a protocol handle returned from the given DLL.
HRESULT CCommProtocolCreate( IN LPCWSTR cwszDLL, IN HCOMMPROTOCOL* phCommProtocol ); Parameters cwszDLL Protocol DLL. phCommProtocol Pointer to communications protocol handle. - CommProtocolClientOpen: this method attempts to open a connection to a server using the connection information in the given header before the given timeout occurs.
HRESULT CommProtocolClientOpen( IN HCOMMPROTOCOL hCommProtocol, IN LPCWSTR cwszHeader, IN DWORD dwTimeout ); Parameters hCommProtocol communications protocol handle. cwszHeader XML header in CommProtocol format. dwTimeout Timeout. - CommProtocolSend: this method attempts to send the given data before the given timeout occurs.
HRESULT CommProtocolSend( IN HCOMMPROTOCOL hCommProtocol, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hCommProtocol communications protocol handle. dwDataSize Data size. pbData Data. dwTimeout Maximum time to wait to send all data. - CommProtocolReceive: this method attempts to receive the given data before the timeout occurs.
HRESULT CommProtocolReceive( IN HCOMMPROTOCOL hCommProtocol, IN DWORD dwDataSize, IN LPBYTE pbData, IN DWORD dwTimeout ); Parameters hCommProtocol communications protocol handle. dwBufferSize Data size. pbBuffer Data. dwTimeout Maximum time to wait to receive all data. - CommProtocolServerInit: This method attempts to initialize a server connection for accepting client connections with the connection information in the given header.
HRESULT CommProtocolServerInit( IN HCOMMPROTOCOL hCommProtocol, IN LPCWSTR cwszHeader ); Parameters hCommProtocol communications protocol handle. cwszHeader XML header in CommProtocol format. - CommProtocolServerOpen: this method attempts to open a client connection before the given timeout occurs.
HRESULT CommProtocolServerOpen( IN HCOMMPROTOCOL hCommProtocol, IN DWORD dwTimeout, OUT HCOMMPROTOCOL* phCommProtocol ); Parameters hCommProtocol Server communications protocol handle. dwTimeout Timeout. phCommProtocol Pointer to client communications protocol handle. - CommProtocolClose: this method attempts to close the connection associated with the given protocol handle.
HRESULT CommProtocolClose( IN HCOMMPROTOCOL hCommProtocol ); Parameters hCommProtocol communications protocol handle. - CommProtocolDelete: this method deletes the given protocol handle.
HRESULT CommProtocolDelete( IN HCOMMPROTOCOL hCommProtocol ); Parameters hCommProtocol communications protocol handle. - In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
Claims (14)
1-41. (canceled)
42. A computer-readable medium having stored thereon a message header markup language data structure, the message header comprising:
a first data field containing data representing message handling and delivery characteristics;
a second data field containing data representing a message; and
a third data field containing data representing a communications header.
43. The computer-readable medium of claim 42 wherein the message comprises:
a fourth data field containing data representing a unique identifier for the message; and
a fifth data field containing data representing a target message handler for the message.
44. The computer-readable medium of claim 43 wherein the unique identifier for the message is a GUID.
45. The computer-readable medium of claim 43 wherein the message further comprises:
a sixth data field containing data representing a retry interval for the message; and
a seventh data field containing data representing a delivery timeout interval for the message.
46. The computer-readable medium of claim 42 wherein the Message Header further comprises:
a fourth data field containing data representing a reply.
47. The computer-readable medium of claim 42 wherein the communications header comprises:
a fourth data field containing data representing connection characteristics; and
a fifth data field containing data representing a communications protocol.
48. The computer-readable medium of claim 47 wherein the communications header further comprises:
a sixth data field containing data representing communications security; and
a seventh data field containing data representing a reply route.
49. A method for communicating between an application and a message layer, the method comprising:
issuing, by the message layer, a message handler call with input parameters comprising a message header, a payload type, a payload size, a payload, and a message context;
receiving, by the application, the message handler call and parsing the call to retrieve the input parameters; and
issuing, by the application, a return to the message handler return call with output parameters comprising a reply type, a reply size, and a reply.
50. The method of claim 49 wherein the message header is in a markup language format.
51. The method of claim 49 wherein the payload type and the reply type are selected from the group consisting of: binary and a markup language.
52. A computer-readable medium having computer-executable instructions for performing a method for communicating between an application and a message layer, the method comprising:
issuing, by the message layer, a message handler call with input parameters comprising a message header, a payload type, a payload size, a payload, and a message context;
receiving, by the application, the message handler call and parsing the call to retrieve the input parameters; and
issuing, by the application, a return to the message handler return call with output parameters comprising a reply type, a reply size, and a reply.
53. The computer-readable medium of claim 52 wherein the message header is in a markup language format.
54. The computer-readable medium of claim method of claim 52 wherein the payload type and the reply type are selected from the group consisting of: binary and a markup language.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/135,933 US20050216727A1 (en) | 2003-08-29 | 2005-05-23 | Communication stack for network communication and routing |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/651,780 US7191248B2 (en) | 2003-08-29 | 2003-08-29 | Communication stack for network communication and routing |
US11/135,933 US20050216727A1 (en) | 2003-08-29 | 2005-05-23 | Communication stack for network communication and routing |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/651,780 Continuation US7191248B2 (en) | 2003-08-29 | 2003-08-29 | Communication stack for network communication and routing |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050216727A1 true US20050216727A1 (en) | 2005-09-29 |
Family
ID=34217479
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/651,780 Active 2024-09-08 US7191248B2 (en) | 2003-08-29 | 2003-08-29 | Communication stack for network communication and routing |
US11/135,933 Abandoned US20050216727A1 (en) | 2003-08-29 | 2005-05-23 | Communication stack for network communication and routing |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/651,780 Active 2024-09-08 US7191248B2 (en) | 2003-08-29 | 2003-08-29 | Communication stack for network communication and routing |
Country Status (1)
Country | Link |
---|---|
US (2) | US7191248B2 (en) |
Cited By (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040267772A1 (en) * | 2003-06-30 | 2004-12-30 | Perloff Ronals S. | Apparatus, system and method for updating a sorted list |
US20060123226A1 (en) * | 2004-12-07 | 2006-06-08 | Sandeep Kumar | Performing security functions on a message payload in a network element |
US20060129689A1 (en) * | 2004-12-10 | 2006-06-15 | Ricky Ho | Reducing the sizes of application layer messages in a network element |
US20060146879A1 (en) * | 2005-01-05 | 2006-07-06 | Tefcros Anthias | Interpreting an application message at a network element using sampling and heuristics |
US20060155862A1 (en) * | 2005-01-06 | 2006-07-13 | Hari Kathi | Data traffic load balancing based on application layer messages |
US20060168334A1 (en) * | 2005-01-25 | 2006-07-27 | Sunil Potti | Application layer message-based server failover management by a network element |
US20080022389A1 (en) * | 2006-07-18 | 2008-01-24 | Motorola, Inc. | Method and apparatus for dynamic, seamless security in communication protocols |
US7345585B2 (en) | 2005-08-01 | 2008-03-18 | Cisco Technology, Inc. | Network based device for providing RFID middleware functionality |
US7509431B2 (en) | 2004-11-17 | 2009-03-24 | Cisco Technology, Inc. | Performing message and transformation adapter functions in a network element on behalf of an application |
US7664879B2 (en) | 2004-11-23 | 2010-02-16 | Cisco Technology, Inc. | Caching content and state data at a network element |
US7725934B2 (en) | 2004-12-07 | 2010-05-25 | Cisco Technology, Inc. | Network and application attack protection based on application layer message inspection |
US20110138075A1 (en) * | 2008-08-01 | 2011-06-09 | Tajitshu Transfer Limited Liability Company | Multi-homed data forwarding storage |
US20110167131A1 (en) * | 2008-04-25 | 2011-07-07 | Tajitshu Transfer Limited Liability Company | Real-time communications over data forwarding framework |
US20110173069A1 (en) * | 2008-07-10 | 2011-07-14 | Tajitshu Transfer Limited Liability Company | Advertisement forwarding storage and retrieval network |
US20110170547A1 (en) * | 2008-09-29 | 2011-07-14 | Tajitshu Transfer Limited Liability Company | Geolocation assisted data forwarding storage |
US20110179120A1 (en) * | 2008-09-29 | 2011-07-21 | Tajitshu Transfer Limited Liability Company | Selective data forwarding storage |
US20110179131A1 (en) * | 2008-07-10 | 2011-07-21 | Tajitshu Transfer Limited Liability Company | Media delivery in data forwarding storage network |
US7987272B2 (en) | 2004-12-06 | 2011-07-26 | Cisco Technology, Inc. | Performing message payload processing functions in a network element on behalf of an application |
US8060623B2 (en) | 2004-05-13 | 2011-11-15 | Cisco Technology, Inc. | Automated configuration of network device ports |
US8082304B2 (en) | 2004-12-10 | 2011-12-20 | Cisco Technology, Inc. | Guaranteed delivery of application layer messages by a network element |
US20120331239A1 (en) * | 2007-05-31 | 2012-12-27 | Broadcom Corporation | Shared memory architecture |
US8452844B2 (en) | 2008-05-07 | 2013-05-28 | Tajitshu Transfer Limited Liability Company | Deletion in data file forwarding framework |
US8458285B2 (en) | 2008-03-20 | 2013-06-04 | Post Dahl Co. Limited Liability Company | Redundant data forwarding storage |
US8489687B2 (en) | 2008-09-29 | 2013-07-16 | Tajitshu Transfer Limited Liability Company | Rotating encryption in data forwarding storage |
US8554866B2 (en) | 2008-09-29 | 2013-10-08 | Tajitshu Transfer Limited Liability Company | Measurement in data forwarding storage |
US20150331727A1 (en) * | 2014-05-16 | 2015-11-19 | Microsoft Corporation | Code service for language-independent dispatch |
US9203928B2 (en) | 2008-03-20 | 2015-12-01 | Callahan Cellular L.L.C. | Data storage and retrieval |
US20210044849A1 (en) * | 2015-10-12 | 2021-02-11 | The Nielsen Company (Us), Llc | Methods and apparatus to identify co-relationships between media using social media |
Families Citing this family (59)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8296433B2 (en) * | 2002-05-22 | 2012-10-23 | International Business Machines Corporation | Virtualization method and apparatus for integrating enterprise applications |
US7610404B2 (en) * | 2002-05-22 | 2009-10-27 | Cast Iron Systems, Inc. | Application network communication method and apparatus |
KR100477513B1 (en) * | 2002-11-25 | 2005-03-17 | 전자부품연구원 | Architecture and method of a common protocol for transferring data between different network protocols and a common protocol packet |
US8321590B2 (en) | 2003-05-22 | 2012-11-27 | International Business Machines Corporation | Application network communication |
CN1833403B (en) * | 2003-08-08 | 2011-05-25 | 小川惠子 | Communication system, communication device and communication method |
GB2426161A (en) * | 2005-05-13 | 2006-11-15 | Onshare Ltd | Networking via a communication layer |
US7694287B2 (en) * | 2005-06-29 | 2010-04-06 | Visa U.S.A. | Schema-based dynamic parse/build engine for parsing multi-format messages |
WO2007064876A2 (en) * | 2005-12-01 | 2007-06-07 | Firestar Software, Inc. | System and method for exchanging information among exchange applications |
EP1936907A1 (en) * | 2006-12-12 | 2008-06-25 | The Sporting Exchange Ltd. | Transaction processing system |
US8548428B2 (en) | 2009-01-28 | 2013-10-01 | Headwater Partners I Llc | Device group partitions and settlement platform |
US8275830B2 (en) | 2009-01-28 | 2012-09-25 | Headwater Partners I Llc | Device assisted CDR creation, aggregation, mediation and billing |
US8346225B2 (en) | 2009-01-28 | 2013-01-01 | Headwater Partners I, Llc | Quality of service for device assisted services |
US8583781B2 (en) | 2009-01-28 | 2013-11-12 | Headwater Partners I Llc | Simplified service network architecture |
US8832777B2 (en) | 2009-03-02 | 2014-09-09 | Headwater Partners I Llc | Adapting network policies based on device service processor configuration |
US8626115B2 (en) | 2009-01-28 | 2014-01-07 | Headwater Partners I Llc | Wireless network service interfaces |
US8589541B2 (en) | 2009-01-28 | 2013-11-19 | Headwater Partners I Llc | Device-assisted services for protecting network capacity |
US8402111B2 (en) | 2009-01-28 | 2013-03-19 | Headwater Partners I, Llc | Device assisted services install |
US8340634B2 (en) | 2009-01-28 | 2012-12-25 | Headwater Partners I, Llc | Enhanced roaming services and converged carrier networks with device assisted services and a proxy |
US8635335B2 (en) | 2009-01-28 | 2014-01-21 | Headwater Partners I Llc | System and method for wireless network offloading |
US8406748B2 (en) | 2009-01-28 | 2013-03-26 | Headwater Partners I Llc | Adaptive ambient services |
US9572019B2 (en) | 2009-01-28 | 2017-02-14 | Headwater Partners LLC | Service selection set published to device agent with on-device service selection |
US9954975B2 (en) | 2009-01-28 | 2018-04-24 | Headwater Research Llc | Enhanced curfew and protection associated with a device group |
US10264138B2 (en) | 2009-01-28 | 2019-04-16 | Headwater Research Llc | Mobile device and service management |
US9578182B2 (en) | 2009-01-28 | 2017-02-21 | Headwater Partners I Llc | Mobile device and service management |
US10783581B2 (en) | 2009-01-28 | 2020-09-22 | Headwater Research Llc | Wireless end-user device providing ambient or sponsored services |
US10057775B2 (en) | 2009-01-28 | 2018-08-21 | Headwater Research Llc | Virtualized policy and charging system |
US9571559B2 (en) | 2009-01-28 | 2017-02-14 | Headwater Partners I Llc | Enhanced curfew and protection associated with a device group |
US9955332B2 (en) | 2009-01-28 | 2018-04-24 | Headwater Research Llc | Method for child wireless device activation to subscriber account of a master wireless device |
US10779177B2 (en) | 2009-01-28 | 2020-09-15 | Headwater Research Llc | Device group partitions and settlement platform |
US10326800B2 (en) | 2009-01-28 | 2019-06-18 | Headwater Research Llc | Wireless network service interfaces |
US9706061B2 (en) | 2009-01-28 | 2017-07-11 | Headwater Partners I Llc | Service design center for device assisted services |
US9565707B2 (en) | 2009-01-28 | 2017-02-07 | Headwater Partners I Llc | Wireless end-user device with wireless data attribution to multiple personas |
US10798252B2 (en) | 2009-01-28 | 2020-10-06 | Headwater Research Llc | System and method for providing user notifications |
US10484858B2 (en) | 2009-01-28 | 2019-11-19 | Headwater Research Llc | Enhanced roaming services and converged carrier networks with device assisted services and a proxy |
US9557889B2 (en) | 2009-01-28 | 2017-01-31 | Headwater Partners I Llc | Service plan design, user interfaces, application programming interfaces, and device management |
US10715342B2 (en) | 2009-01-28 | 2020-07-14 | Headwater Research Llc | Managing service user discovery and service launch object placement on a device |
US10841839B2 (en) | 2009-01-28 | 2020-11-17 | Headwater Research Llc | Security, fraud detection, and fraud mitigation in device-assisted services systems |
US9647918B2 (en) | 2009-01-28 | 2017-05-09 | Headwater Research Llc | Mobile device and method attributing media services network usage to requesting application |
US9392462B2 (en) | 2009-01-28 | 2016-07-12 | Headwater Partners I Llc | Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy |
US10248996B2 (en) | 2009-01-28 | 2019-04-02 | Headwater Research Llc | Method for operating a wireless end-user device mobile payment agent |
US10064055B2 (en) | 2009-01-28 | 2018-08-28 | Headwater Research Llc | Security, fraud detection, and fraud mitigation in device-assisted services systems |
US9609510B2 (en) | 2009-01-28 | 2017-03-28 | Headwater Research Llc | Automated credential porting for mobile devices |
US11218854B2 (en) | 2009-01-28 | 2022-01-04 | Headwater Research Llc | Service plan design, user interfaces, application programming interfaces, and device management |
US9980146B2 (en) | 2009-01-28 | 2018-05-22 | Headwater Research Llc | Communications device with secure data path processing agents |
US10492102B2 (en) | 2009-01-28 | 2019-11-26 | Headwater Research Llc | Intermediate networking devices |
US10237757B2 (en) | 2009-01-28 | 2019-03-19 | Headwater Research Llc | System and method for wireless network offloading |
US10200541B2 (en) | 2009-01-28 | 2019-02-05 | Headwater Research Llc | Wireless end-user device with divided user space/kernel space traffic policy system |
US9858559B2 (en) | 2009-01-28 | 2018-01-02 | Headwater Research Llc | Network service plan design |
US9270559B2 (en) | 2009-01-28 | 2016-02-23 | Headwater Partners I Llc | Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow |
TW201037468A (en) * | 2009-04-03 | 2010-10-16 | Lan-Yan Zhang | Image capturing method and structure for origin target |
US8806190B1 (en) | 2010-04-19 | 2014-08-12 | Amaani Munshi | Method of transmission of encrypted documents from an email application |
US9563751B1 (en) | 2010-10-13 | 2017-02-07 | The Boeing Company | License utilization management system service suite |
EP2498538A1 (en) * | 2011-03-11 | 2012-09-12 | Rayzon Technologies AG | Mobile communication device |
US9825952B2 (en) | 2011-12-30 | 2017-11-21 | Intel Corporation | Secure machine to machine communication |
US9513981B2 (en) | 2014-11-05 | 2016-12-06 | International Business Machines Corporation | Communication software stack optimization using distributed error checking |
US11061802B2 (en) | 2016-10-17 | 2021-07-13 | Zomojo Pty Ltd | Precision time stamping method and system |
US10791091B1 (en) * | 2018-02-13 | 2020-09-29 | Architecture Technology Corporation | High assurance unified network switch |
AU2020251395A1 (en) | 2019-04-01 | 2021-09-16 | Zomojo Pty Ltd | A method and apparatus for network time syncing |
EP3991350A4 (en) | 2019-06-25 | 2023-08-02 | Cisco Technology, Inc. | A method and apparatus for high precision time stamping |
Citations (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5764915A (en) * | 1996-03-08 | 1998-06-09 | International Business Machines Corporation | Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack |
US5778189A (en) * | 1996-05-29 | 1998-07-07 | Fujitsu Limited | System and method for converting communication protocols |
US5920703A (en) * | 1997-02-19 | 1999-07-06 | International Business Machines Corp. | Systems and methods for managing the processing of relatively large data objects in a communications stack |
US5931900A (en) * | 1997-08-25 | 1999-08-03 | I2 Technologies, Inc. | System and process for inter-domain interaction across an inter-domain connectivity plane |
US5938733A (en) * | 1996-03-08 | 1999-08-17 | International Business Machines Corporation | Object oriented representation of network requests in a client server model |
US6003088A (en) * | 1997-08-29 | 1999-12-14 | International Business Machines Corporation | Blocking IP datagrams in a multi-path channel point-to-point environment |
US6172981B1 (en) * | 1997-10-30 | 2001-01-09 | International Business Machines Corporation | Method and system for distributing network routing functions to local area network stations |
US6233624B1 (en) * | 1997-05-08 | 2001-05-15 | Microsoft Corporation | System and method for layering drivers |
US6273622B1 (en) * | 1997-04-15 | 2001-08-14 | Flash Networks, Ltd. | Data communication protocol for maximizing the performance of IP communication links |
US20020091863A1 (en) * | 1997-11-17 | 2002-07-11 | Schug Klaus H. | Interoperable network communication architecture |
US20020199013A1 (en) * | 2001-06-25 | 2002-12-26 | Sorensen Lauge S. | Method and apparatus for moving HTML/XML information into a HTTP header in a network |
US20030172167A1 (en) * | 2002-03-08 | 2003-09-11 | Paul Judge | Systems and methods for secure communication delivery |
US20040194101A1 (en) * | 1997-08-21 | 2004-09-30 | Glanzer David A. | Flexible function blocks |
US20050050549A1 (en) * | 2003-08-26 | 2005-03-03 | International Busniess Machines Corporation | Method and system for dynamically associating type information and creating and processing meta-data in a service oriented architecture |
US7162535B2 (en) * | 2001-03-26 | 2007-01-09 | First Hop Oy | Methods and arrangements for providing efficient information transfer over a limited-speed communications link |
US7240327B2 (en) * | 2003-06-04 | 2007-07-03 | Sap Ag | Cross-platform development for devices with heterogeneous capabilities |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5657390A (en) * | 1995-08-25 | 1997-08-12 | Netscape Communications Corporation | Secure socket layer application program apparatus and method |
US6934249B1 (en) * | 1997-04-01 | 2005-08-23 | Cisco Technology, Inc. | Method and system for minimizing the connection set up time in high speed packet switching networks |
US6148336A (en) * | 1998-03-13 | 2000-11-14 | Deterministic Networks, Inc. | Ordering of multiple plugin applications using extensible layered service provider with network traffic filtering |
US6141686A (en) * | 1998-03-13 | 2000-10-31 | Deterministic Networks, Inc. | Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control |
US6853988B1 (en) * | 1999-09-20 | 2005-02-08 | Security First Corporation | Cryptographic server with provisions for interoperability between cryptographic systems |
US6631416B2 (en) * | 2000-04-12 | 2003-10-07 | Openreach Inc. | Methods and systems for enabling a tunnel between two computers on a network |
US6912522B2 (en) * | 2000-09-11 | 2005-06-28 | Ablesoft, Inc. | System, method and computer program product for optimization and acceleration of data transport and processing |
US7107619B2 (en) * | 2001-08-31 | 2006-09-12 | International Business Machines Corporation | System and method for the detection of and reaction to denial of service attacks |
US6823437B2 (en) * | 2002-07-11 | 2004-11-23 | International Business Machines Corporation | Lazy deregistration protocol for a split socket stack |
-
2003
- 2003-08-29 US US10/651,780 patent/US7191248B2/en active Active
-
2005
- 2005-05-23 US US11/135,933 patent/US20050216727A1/en not_active Abandoned
Patent Citations (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5938733A (en) * | 1996-03-08 | 1999-08-17 | International Business Machines Corporation | Object oriented representation of network requests in a client server model |
US5764915A (en) * | 1996-03-08 | 1998-06-09 | International Business Machines Corporation | Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack |
US5778189A (en) * | 1996-05-29 | 1998-07-07 | Fujitsu Limited | System and method for converting communication protocols |
US5920703A (en) * | 1997-02-19 | 1999-07-06 | International Business Machines Corp. | Systems and methods for managing the processing of relatively large data objects in a communications stack |
US6273622B1 (en) * | 1997-04-15 | 2001-08-14 | Flash Networks, Ltd. | Data communication protocol for maximizing the performance of IP communication links |
US6233624B1 (en) * | 1997-05-08 | 2001-05-15 | Microsoft Corporation | System and method for layering drivers |
US20040194101A1 (en) * | 1997-08-21 | 2004-09-30 | Glanzer David A. | Flexible function blocks |
US5931900A (en) * | 1997-08-25 | 1999-08-03 | I2 Technologies, Inc. | System and process for inter-domain interaction across an inter-domain connectivity plane |
US6003088A (en) * | 1997-08-29 | 1999-12-14 | International Business Machines Corporation | Blocking IP datagrams in a multi-path channel point-to-point environment |
US6172981B1 (en) * | 1997-10-30 | 2001-01-09 | International Business Machines Corporation | Method and system for distributing network routing functions to local area network stations |
US20020091863A1 (en) * | 1997-11-17 | 2002-07-11 | Schug Klaus H. | Interoperable network communication architecture |
US7162535B2 (en) * | 2001-03-26 | 2007-01-09 | First Hop Oy | Methods and arrangements for providing efficient information transfer over a limited-speed communications link |
US20020199013A1 (en) * | 2001-06-25 | 2002-12-26 | Sorensen Lauge S. | Method and apparatus for moving HTML/XML information into a HTTP header in a network |
US20030172167A1 (en) * | 2002-03-08 | 2003-09-11 | Paul Judge | Systems and methods for secure communication delivery |
US7240327B2 (en) * | 2003-06-04 | 2007-07-03 | Sap Ag | Cross-platform development for devices with heterogeneous capabilities |
US20050050549A1 (en) * | 2003-08-26 | 2005-03-03 | International Busniess Machines Corporation | Method and system for dynamically associating type information and creating and processing meta-data in a service oriented architecture |
Cited By (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7197498B2 (en) * | 2003-06-30 | 2007-03-27 | Intel Corporation | Apparatus, system and method for updating a sorted list |
US20040267772A1 (en) * | 2003-06-30 | 2004-12-30 | Perloff Ronals S. | Apparatus, system and method for updating a sorted list |
US8060623B2 (en) | 2004-05-13 | 2011-11-15 | Cisco Technology, Inc. | Automated configuration of network device ports |
US8601143B2 (en) | 2004-05-13 | 2013-12-03 | Cisco Technology, Inc. | Automated configuration of network device ports |
US7509431B2 (en) | 2004-11-17 | 2009-03-24 | Cisco Technology, Inc. | Performing message and transformation adapter functions in a network element on behalf of an application |
US8799403B2 (en) | 2004-11-23 | 2014-08-05 | Cisco Technology, Inc. | Caching content and state data at a network element |
US7664879B2 (en) | 2004-11-23 | 2010-02-16 | Cisco Technology, Inc. | Caching content and state data at a network element |
US8549171B2 (en) | 2004-12-06 | 2013-10-01 | Cisco Technology, Inc. | Method and apparatus for high-speed processing of structured application messages in a network device |
US8312148B2 (en) | 2004-12-06 | 2012-11-13 | Cisco Technology, Inc. | Performing message payload processing functions in a network element on behalf of an application |
US7987272B2 (en) | 2004-12-06 | 2011-07-26 | Cisco Technology, Inc. | Performing message payload processing functions in a network element on behalf of an application |
US9380008B2 (en) | 2004-12-06 | 2016-06-28 | Cisco Technology, Inc. | Method and apparatus for high-speed processing of structured application messages in a network device |
US7996556B2 (en) | 2004-12-06 | 2011-08-09 | Cisco Technology, Inc. | Method and apparatus for generating a network topology representation based on inspection of application messages at a network device |
US7496750B2 (en) * | 2004-12-07 | 2009-02-24 | Cisco Technology, Inc. | Performing security functions on a message payload in a network element |
US20060123226A1 (en) * | 2004-12-07 | 2006-06-08 | Sandeep Kumar | Performing security functions on a message payload in a network element |
US7725934B2 (en) | 2004-12-07 | 2010-05-25 | Cisco Technology, Inc. | Network and application attack protection based on application layer message inspection |
US8082304B2 (en) | 2004-12-10 | 2011-12-20 | Cisco Technology, Inc. | Guaranteed delivery of application layer messages by a network element |
US20060129689A1 (en) * | 2004-12-10 | 2006-06-15 | Ricky Ho | Reducing the sizes of application layer messages in a network element |
US20060146879A1 (en) * | 2005-01-05 | 2006-07-06 | Tefcros Anthias | Interpreting an application message at a network element using sampling and heuristics |
US7551567B2 (en) | 2005-01-05 | 2009-06-23 | Cisco Technology, Inc. | Interpreting an application message at a network element using sampling and heuristics |
US20060155862A1 (en) * | 2005-01-06 | 2006-07-13 | Hari Kathi | Data traffic load balancing based on application layer messages |
US20060168334A1 (en) * | 2005-01-25 | 2006-07-27 | Sunil Potti | Application layer message-based server failover management by a network element |
US7698416B2 (en) | 2005-01-25 | 2010-04-13 | Cisco Technology, Inc. | Application layer message-based server failover management by a network element |
US8843598B2 (en) | 2005-08-01 | 2014-09-23 | Cisco Technology, Inc. | Network based device for providing RFID middleware functionality |
US7345585B2 (en) | 2005-08-01 | 2008-03-18 | Cisco Technology, Inc. | Network based device for providing RFID middleware functionality |
US20080022389A1 (en) * | 2006-07-18 | 2008-01-24 | Motorola, Inc. | Method and apparatus for dynamic, seamless security in communication protocols |
US20110075845A1 (en) * | 2006-07-18 | 2011-03-31 | Motorola, Inc. | Method and apparatus for dynamic, seamless security in communication protocols |
US7865717B2 (en) | 2006-07-18 | 2011-01-04 | Motorola, Inc. | Method and apparatus for dynamic, seamless security in communication protocols |
US8245028B2 (en) | 2006-07-18 | 2012-08-14 | Motorola Solutions, Inc. | Method and apparatus for dynamic, seamless security in communication protocols |
US8812795B2 (en) * | 2007-05-31 | 2014-08-19 | Broadcom Corporation | Shared memory architecture |
US20120331239A1 (en) * | 2007-05-31 | 2012-12-27 | Broadcom Corporation | Shared memory architecture |
US9203928B2 (en) | 2008-03-20 | 2015-12-01 | Callahan Cellular L.L.C. | Data storage and retrieval |
US9961144B2 (en) | 2008-03-20 | 2018-05-01 | Callahan Cellular L.L.C. | Data storage and retrieval |
US8909738B2 (en) | 2008-03-20 | 2014-12-09 | Tajitshu Transfer Limited Liability Company | Redundant data forwarding storage |
US8458285B2 (en) | 2008-03-20 | 2013-06-04 | Post Dahl Co. Limited Liability Company | Redundant data forwarding storage |
US20110167131A1 (en) * | 2008-04-25 | 2011-07-07 | Tajitshu Transfer Limited Liability Company | Real-time communications over data forwarding framework |
US8386585B2 (en) | 2008-04-25 | 2013-02-26 | Tajitshu Transfer Limited Liability Company | Real-time communications over data forwarding framework |
US8452844B2 (en) | 2008-05-07 | 2013-05-28 | Tajitshu Transfer Limited Liability Company | Deletion in data file forwarding framework |
US20110179131A1 (en) * | 2008-07-10 | 2011-07-21 | Tajitshu Transfer Limited Liability Company | Media delivery in data forwarding storage network |
US8599678B2 (en) * | 2008-07-10 | 2013-12-03 | Tajitshu Transfer Limited Liability Company | Media delivery in data forwarding storage network |
US20110173069A1 (en) * | 2008-07-10 | 2011-07-14 | Tajitshu Transfer Limited Liability Company | Advertisement forwarding storage and retrieval network |
US8370446B2 (en) | 2008-07-10 | 2013-02-05 | Tajitshu Transfer Limited Liability Company | Advertisement forwarding storage and retrieval network |
US8356078B2 (en) | 2008-08-01 | 2013-01-15 | Tajitshu Transfer Limited Liability Company | Multi-homed data forwarding storage |
US20110138075A1 (en) * | 2008-08-01 | 2011-06-09 | Tajitshu Transfer Limited Liability Company | Multi-homed data forwarding storage |
US20110179120A1 (en) * | 2008-09-29 | 2011-07-21 | Tajitshu Transfer Limited Liability Company | Selective data forwarding storage |
US8489687B2 (en) | 2008-09-29 | 2013-07-16 | Tajitshu Transfer Limited Liability Company | Rotating encryption in data forwarding storage |
US8478823B2 (en) | 2008-09-29 | 2013-07-02 | Tajitshu Transfer Limited Liability Company | Selective data forwarding storage |
US8352635B2 (en) | 2008-09-29 | 2013-01-08 | Tajitshu Transfer Limited Liability Company | Geolocation assisted data forwarding storage |
US8554866B2 (en) | 2008-09-29 | 2013-10-08 | Tajitshu Transfer Limited Liability Company | Measurement in data forwarding storage |
US20110170547A1 (en) * | 2008-09-29 | 2011-07-14 | Tajitshu Transfer Limited Liability Company | Geolocation assisted data forwarding storage |
US20150331727A1 (en) * | 2014-05-16 | 2015-11-19 | Microsoft Corporation | Code service for language-independent dispatch |
KR20170003578A (en) * | 2014-05-16 | 2017-01-09 | 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 | Code service for language-independent dispatch |
US9760415B2 (en) * | 2014-05-16 | 2017-09-12 | Microsoft Technology Licensing, Llc | Code service for language-independent dispatch |
KR102354717B1 (en) | 2014-05-16 | 2022-01-21 | 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 | Code service for language-independent dispatch |
US20210044849A1 (en) * | 2015-10-12 | 2021-02-11 | The Nielsen Company (Us), Llc | Methods and apparatus to identify co-relationships between media using social media |
US11638053B2 (en) * | 2015-10-12 | 2023-04-25 | The Nielsen Company (Us), Llc | Methods and apparatus to identify co-relationships between media using social media |
Also Published As
Publication number | Publication date |
---|---|
US7191248B2 (en) | 2007-03-13 |
US20050050203A1 (en) | 2005-03-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7191248B2 (en) | Communication stack for network communication and routing | |
US10931649B2 (en) | Secure end-to-end transport through intermediary nodes | |
US8001189B2 (en) | Routing of network messages | |
JP4965574B2 (en) | Port sharing among multiple processes | |
US8392700B2 (en) | Apparatus and system for asymmetric security | |
AU2005234675B2 (en) | Bulk transmission of messages using a single HTTP request | |
US7933261B2 (en) | Communication method, communication system, communication device, and program using multiple communication modes | |
KR101201140B1 (en) | Reliable one-way messaging over request-response transport protocols | |
US20120054851A1 (en) | Systems and methods for multiplexing network channels | |
US20030074482A1 (en) | Composable messaging protocol | |
US20080215877A1 (en) | Offload Processing for Secure Data Transfer | |
US9912735B2 (en) | Intercepting file transfers in multi-node topologies | |
US20080077788A1 (en) | Secure Tunnel Over HTTPS Connection | |
US20080294778A1 (en) | Network connection manager | |
US7543067B2 (en) | Flexible secure network data transfer and messaging | |
US20070022284A1 (en) | Method, cluster system and computer-readable medium for distributing data packets | |
US7502922B1 (en) | Computer network having a security layer interface independent of the application transport mechanism | |
US8601094B2 (en) | Method and computer program product utilizing multiple UDP data packets to transfer a quantity of data otherwise in excess of a single UDP packet | |
US20090024739A1 (en) | Endpoint discriminator in network transport protocol startup packets | |
US8285858B2 (en) | Signaling using binary form of SIP messages | |
JP7395615B2 (en) | Data leak prevention | |
Sharp | The poor man’s guide to computer networks and their applications | |
Pauly et al. | TAPS Working Group B. Trammell Internet-Draft ETH Zurich Intended status: Informational C. Perkins Expires: April 30, 2018 University of Glasgow | |
Pauly et al. | TAPS Working Group B. Trammell Internet-Draft ETH Zurich Intended status: Informational C. Perkins Expires: March 12, 2018 University of Glasgow | |
Wenzel et al. | OASIS ebXML Messaging Services 3.0 Conformance Profiles |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001 Effective date: 20141014 |