WO2011071543A2 - Système de substrat-réseau transparent - Google Patents

Système de substrat-réseau transparent Download PDF

Info

Publication number
WO2011071543A2
WO2011071543A2 PCT/US2010/003165 US2010003165W WO2011071543A2 WO 2011071543 A2 WO2011071543 A2 WO 2011071543A2 US 2010003165 W US2010003165 W US 2010003165W WO 2011071543 A2 WO2011071543 A2 WO 2011071543A2
Authority
WO
WIPO (PCT)
Prior art keywords
tns
class
server
functionality
name
Prior art date
Application number
PCT/US2010/003165
Other languages
English (en)
Other versions
WO2011071543A3 (fr
Inventor
Kevin Stallard
Original Assignee
Aerial Robotics, Inc.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Aerial Robotics, Inc. filed Critical Aerial Robotics, Inc.
Priority to CA2783829A priority Critical patent/CA2783829C/fr
Priority to US13/514,329 priority patent/US9135055B2/en
Priority to BR112012013808-1A priority patent/BR112012013808B1/pt
Publication of WO2011071543A2 publication Critical patent/WO2011071543A2/fr
Publication of WO2011071543A3 publication Critical patent/WO2011071543A3/fr
Priority to US14/853,820 priority patent/US9672014B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/37—Compiler construction; Parser generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • 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/01—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/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/541—Client-server

Definitions

  • Newer computer languages have simplified this process. However these newer languages most often found on a narrow range of operating system platforms (Microsoft' Windows, for example) and are not available on real-time and safety critical systems. Furthermore, these languages provide difficulty for developers of safety critical systems as they will sometimes perform operations and exhibit behavior that is incompatible with the validation requirements for such systems. For example, some languages perform automatic (and sometimes unpredictable and unbounded) operations that have not been specifically requested by the programmer. While these are considered useful in insuring reliability of general purpose applications, they may be detrimental to specialized systems. Garbage collection is one example, this is where a programs execution is interrupted while memory that is deemed unused is returned to the pool of usable memory.
  • COM/DCOM and CORBA have to use an additional compilation step to correctly expose interfaces contained within, for example, a C/C++ program.
  • Building C/C++ programs requires two steps known as the pre-processor step (preparing the code for the compiler) and the compiler step (conversion of C/C++ code into machine language). Both of these operations are performed by the compiler executable itself.
  • a separate file containing the desired exposed interface called an interface definition language (IDL) must be prepared and run through a separate compiler that understands this IDL.
  • IDL interface definition language
  • the IDL compiler step results in a file that is separate from the binary containing descriptive information about the interface as well as other artifacts. These are not included with the binary and therefore are vulnerable to becoming out of sync with the binary.
  • TNS Transparent Network Substrate
  • Interface definitions are created dynamically, and are part of the executable, this removes the chance of it getting corrupted or out of sync with currently installed software. Instead of having to install a number of files and configuration settings, only one executable is needed to run on the target system.
  • Executable entities that require functionality from TNS enabled executable entities (servers) can learn the server's interface at run-time from the server process. This opens the door for intelligent interface discovery and increases a system's potential for truly dynamic self- behavior modification.
  • Clients can dynamically decide if the interface is callable or make adjustments to the data sent to match the interface. 8. No otlner files are required, only the binary containing the executable code is required. No other 'layers' of software need to be installed on the computer using TNS.
  • TNS provides several benefits not found in current state of the art systems. They are:
  • TNS provides the compiler specific source code necessary for the compiler to generate source code and the machine code necessary to perform the complex operations needed to make remote functionality invocation possible.
  • the TNS system is implemented on a non-transitory machine readable storage medium that includes machine code for instructing a microprocessor.
  • the machine code may include at least one server module and at least one client module.
  • the server module includes server machine code that provides a selected functionality, such as moving an actuator, performing a mathematical operation, receiving data from a sensor, and combinations thereof. Upon execution the server machine code writes information necessary to describe the selected functionality to a memory device.
  • the information written to memory includes information necessary to invoke the server module functionality and may include types, members, and parameters.
  • the server machine code uses the information in memory for creating dynamic function calls.
  • the client module includes client machine code that searches the memory for the server providing the selected functionality; requests information from the server module about the functionality; and invokes the functionality of the server module.
  • the client module includes interface query functionality including client machine code for retrieving types; retrieving all of the members for each type; and retrieving all of the parameters for each member.
  • the client module includes data marshalling functionality that determines if the parameters are fixed or variable in length and captures the length of parameters that are determined to be variable in length.
  • a parameter may be accompanied by a data length parameter and the client module is operative to store an address of the parameter and the data length parameter in an input output vector.
  • the server machine code may be generated by a compiler running on a microprocessor from server source code.
  • the server source code includes source code for generating the server machine code that provides the selected functionality.
  • the server source code also includes code for generating server machine code representative of the information and for generating server machine code that is operative to write the machine code representative of the information to the memory device.
  • the compiler includes a preprocessor and at least a portion of the server source code may be created by the preprocessor.
  • the preprocessor uses source code in the form of a macro to create the portion of said server source code. At least a portion of the server source code may be created by the compiler.
  • FIG. 1 is a high level schematic representation of the TNS system architecture
  • FIG. 2 is a diagram illustrating the responsibility boundaries assigned to TNS Servers as well as the functionality it uses to respond to TNS Client requests and properly manage communication with TNS Clients;
  • FIG. 3 is a diagram illustrating the responsibility boundaries assigned to TNS Clients as well as the functionality TNS Clients use to properly communicate with TNS Servers;
  • FIG. 4 is a diagram depicting an exemplary TNS system in one way it might be used
  • Figure 5 is a diagram illustrating the steps the compiler takes in building a TNS enabled executable
  • FIG. 6 is a diagram broadly depicting the TNS client interface query functionality
  • FIG. 7 is a diagram illustrating in more detail the TNS client interface query functionality illustrated in Figure 6;
  • FIG. 8 is a diagram broadly depicting the TNS client to TNS server function invocation process
  • FIG. 9 is diagram illustrating in more detail the TNS client to TNS server function invocation process illustrated in Figure 8.
  • Figure 10 is a diagram illustrating the data marshalling process
  • Figure 11 is a functional block diagram of an exemplary workstation consistent with the technology of the present application.
  • the TNS system is realized in two main parts.
  • the executable that exposes functionality i.e. the ability to move an actuator, do a complex mathematical operation, or retrieve data from a sensor
  • a TNS enabled server also referred to herein as a TNS server, server, or server module.
  • the executable that uses functionality of a TNS Server is called a TNS enabled client, also referred to herein as a TNS client, client, or client module.
  • the term server as used herein refers to a computer program running as a service, to serve the needs or requests of other programs (referred to in this context as "clients") which may or may not be running on the same computer. While the exemplary embodiments are described with respect to C/C++, it is contemplated that other suitable programming languages may be used to implement the TNS system described herein.
  • the TNS system broadly includes a TNS server 10 and a TNS client 50.
  • the TNS server upon execution the TNS server writes 21 information about itself to memory 5.
  • the client 50 retrieves 22 the information in memory 5 in order to find the server and its functionality as well as communicate with the server 10. Using the information, the client 50 can send 24 a message to the server 10 in order to invoke functionality of the server.
  • the server 10 receives a message from the client the server 10 retrieves 26 the information in memory 5 in order to create dynamic function calls.
  • FIG. 2 broadly enumerates the TNS Server 10 process and the fundamental functionality needed to manage connections with TNS Clients.
  • This functionality is in the form of a TNS server stub 20 that includes manage connections functionality 32, manage class instances functionality 34, retrieve class and class interface descriptions 36, and execute requested method calls on class instances 38.
  • the manage connections functionality 32 keeps track of the entities (clients) that are requesting the server's functionality 12. It allows the enforcement of security and access policies as well as provide for data encryption for secure links.
  • the manage connections functionality 32 includes a delete class instance routine 42, which is used to delete the instances of functionality created and used by the client when it disconnects. These instances are sometimes referred to as 'class instances'.
  • Server 10 also includes manage class interface descriptions 44 which allow the compiler generated code in gather and store metadata 48 to record the information gathered at startup 14. It also provides means for retrieve class and class interface descriptions 36 to retrieve the information it sends to a requestor (i.e. a TNS Client).
  • manage class interface descriptions 44 allow the compiler generated code in gather and store metadata 48 to record the information gathered at startup 14. It also provides means for retrieve class and class interface descriptions 36 to retrieve the information it sends to a requestor (i.e. a TNS Client).
  • FIG. 3 illustrates a TNS Client 50 and the functionality it contains to connect to and use a TNS Server 10.
  • This functionality is in the form of a TNS Client Stub 60 that includes find and connect to a server 62, obtain server interface descriptions 64, instantiate server class 66, verify server compatibility 63, call methods on a class 68, and display compatibility report 69.
  • FIG. 4 illustrates an example of a distributed system using TNS.
  • the example includes two TNS enabled servers 110 and 210.
  • TNS server 110 contains the necessary functionality to read a sensor (not shown) that detects rotational motion and TNS server 210 contains the necessary functionality to control a servo (not shown).
  • TNS clients 150, 250, 350, and 450 are each connected to one or more of the TNS servers. Each client has specialized functions they can perform and either need data from the motion sensor or need to control the server or both.
  • the clients connect to the TNS servers using the find and connect to a server functionality 62, retrieve the server's functionality interface using obtain server interface description functionality 64, create instances of functionality on the server through instantiate functionality 66 and verify compatibility functionality 63, and call specific functionality on those instances using call methods on a class functionality 68. If there are mismatches between what the client is expecting to use and what the server provides (in terms of an interface) this information is displayed or reported using display compatibility report functionality 69.
  • TNS In a C++ implementation of TNS, TNS exposes or exports functionality of a TNS Server to TNS Clients by using compiler primitives (aka macros) and templates. These macros and templates gather information or insert code that gathers reflection/metadata information at runtime.
  • compiler primitives aka macros
  • templates These macros and templates gather information or insert code that gathers reflection/metadata information at runtime.
  • Templates are translated into instructions that allow the classes to be instantiated and methods called conditionally. In C++ these are commonly known as 'funktors'.
  • Parse parameter lists and mark parameters intended for data length specification of variable length data. Associate the data length parameter with the parameter containing the variable length data.
  • FIG. 5 illustrates what occurs when a compiler processes the TNS Server source code 430 in an exemplary C++ implementation.
  • Compiler 440 is comprised of three parts, a preprocessor 442, a code generator 444, and a code compiler 446.
  • the compiler 440 reads the code from several reference files in order to resolve the instructions found in server source code 430.
  • Server source code 430 includes a file or files that define the server behavior that is to be exported (i.e. servo motor control routines).
  • the reference files include a header file containing macro definitions 400, a header file containing C++ template definitions 410 that provide means for creating, storing and accessing C++ funktors, and a header file containing template definitions for creating, storing and accessing data type definitions 420.
  • the compiler 440 resolves the server source code in three pre-processor passes.
  • the first pass translates macro statements 400 to the necessary corresponding TNS code that will create the metadata discussed earlier. Once this substitution has completed, the second pass is the code generation where template code is instantiated as needed.
  • the third pass the code is passed into the compiler stage 446 where the object or machine code 455 is generated.
  • Machine code 455 is fed into the linker 495 which combines the machine code 455 with several other support libraries or archives, such as TNS library 470, OS support libraries 480, and libraries to support the C++ language 490.
  • the linker 495 When the linker 495 is finished, it outputs the TNS enabled server executable 460.
  • TNS exportation of a C++ class and its members (definition portion of source code 430). Included in Appendix A are the TNS macros needed to compile this example class.
  • TNS_BEGIN_CLASS_DERIVE() This macro indicates that the C++ class being exported is derived from a base class.
  • the next item is the class constructor.
  • C++ the type footprint of a constructor differs from that of a class method, so TNS provides a distinct macro for constructors. The same applies to destructors.
  • C++ can have static (global) class methods and it can have normal class methods; TNS accounts for both.
  • preprocessor conditionals At the end of the above example file, there are a number of preprocessor conditionals. These allow the class definition file (header file) to have multiple passes made by the C++ preprocessor 442 before it enters the compiler stage 446. This allows macros to be redefined in ways that are needed to capture the information contained as macro parameters.
  • a TNS enabled client that has foreknowledge of the methods it will invoke uses the TNS compiler instructions to do the same things as it does for the server on the methods it will call on the server (i.e. create an in-memory database of the types it will be using to interact with the server).
  • a TNS Client need not know before hand (when it is compiled and built) what functionality a server contains. It can enumerate the functionality of the server and invoke whatever functionality it wishes.
  • the metadata is used to:
  • Information is gathered by the compiler in combination with the compiler generated code to fully describe each of the exported symbols and their type specifications.
  • the information gathered includes:
  • POD plain old datatype
  • an argument represents the length of an argument that references variable length data
  • the name of the argument designating the length of the data is recorded as well as a reference to the argument. This allows the system to associate the data length argument with the argument that will reference the variable length data when communicating with the server.
  • a symbol is of an aggregate type or a class
  • a list of members is recorded. This is recursive until sub aggregates are covered. 3.
  • the information gathered is configured to initialize internal structures at startup. When the program using TNS starts up, these data structures are created and initialized with the information gathered at compile time. This allows the server to have access to a database containing all the information necessary to describe how to access server functionality as well as the capability to instantiate classes and invoke methods without the developer having to hand code.
  • TNS Clients can use the above functionality if the client is to contain 'hints' as to what the server exposes, however it is not required. TNS Clients have instructions included that query TNS Servers for their exposed interfaces. Thus TNS Clients can be 'dumb' in terms of what a server contains and when it is running can dynamically build a table of what a server provides and can then use it to invoke server functionality.
  • TNS Servers and TNS Clients This is accomplished by using a communication mechanism (the native operating system's Inter Process Communication, TCP/IP, or shared memory - TNS does not specify the communication's mechanism) used by both TNS Servers and TNS Clients to pass information between each other.
  • a communication mechanism the native operating system's Inter Process Communication, TCP/IP, or shared memory - TNS does not specify the communication's mechanism
  • the TNS client includes interface query functionality that allows a client to query a server to find out its interface.
  • interface query functionality that allows a client to query a server to find out its interface.
  • there is one immutable interface to TNS enabled servers and this is to be able to acquire additional interface information.
  • a TNS enabled server has some functionality that is always there. This is:
  • the client first uses Get Exported Types to retrieve all the types in the system.
  • the client can optionally review those interfaces to make sure the interfaces it is about to call match. If they do not match, the client can make changes in the way it will call the remote interface or report the mismatch.
  • TNS Transactional Synchronization Protocol
  • the client does not know what functions will be called before hand (i.e. if the client is running a script) it uses this information to determine if the request method or class in the script can be called or instantiated at run time. This allows the client to process a script without any preprocessing.
  • TNS Clients are built with interface information about a TNS Server, when the TNS Client runs, it will still query the server for this same information. It will then compare its internal references to this interface with the references it retrieved from the server. If these interfaces differ, the TNS Client can try to find a way to resolve those differences and provide a safe way to call the interface. If a resolution cannot be found, the interface is disabled and a warning is generated. As an example, the client may expect a floating point input, but for whatever reason the server it is connected to provides an interface that requires a 16-bit integer. The resolution to such a difference in interface is to convert the floating point to a 16 bit integer. If the client encounters an interface to which no conversion is possible, then the interface is disabled and no attempt to call it is made. These rules are provided by the developer of the client and server functionality. In some systems this would be dangerous and therefore not allowed. Any interfaces differences will disable the client and proper error messages would be displayed.
  • TNS Client Once a TNS Client has retrieved, validated, and resolved an interface to a TNS Server it is ready to invoke functionality on the server.
  • the interface information it now contains is converted into instructions in how to place the data into a data stream that is sent to the server. This is called marshaling.
  • the server is expecting the data in a particular format and subsequently retrieves and validates this data before calling the actual functionality.
  • the exported function or method called is a normal method and has no knowledge that it is being used in a TNS system.
  • the TNS takes the results and places them into the data stream that is then sent back to the client.
  • the client because of its knowledge of the interface structure, retrieves the values returned from the method invoked on the TNS Server.
  • the client sends a message to the server that includes the instance id of the class and the method id to be invoked.
  • the server uses the type id to perform a lookup of the method/function prototype. It then decodes the incoming message based on the information found in the method/function prototype definition. The server decodes the instance ID and translates it into an instance of the object that owns the method being called. The server then extracts the data from the message and calls the method. When the message returns, the return data is packaged in the reply message and the server replies to the client.
  • Data Marshalling is the operation necessary to put data onto the wire. Data marshalling is automatic in TNS. In addition to supporting fixed size basic data types (characters, 16, 32, 64 and 128 bit integers, floating point variables, etc), it also supports variable data sized data (character strings and data blobs).
  • variable length data structures are detected. They come in two types; NULL terminated strings and data blobs. Data blobs have to be associated with a member or parameter that will specify the length or maximum length that can be accommodated.
  • Strings do not need a member or parameter that specify the length if it is an input parameter. If a string is going to be an output parameter, a length is necessary. The length is specified by naming the length parameter or member the same name as the parameter or symbol of the string or data blob with a suffix of 'len' added to the symbol or parameter name.
  • TNS will consider foo_namelen to contain the maximum number of characters that can be placed in foo_name.
  • the method dosomethingO has a parameter that will contain some variable length data (either a string or data blob).
  • the last parameter will be interpreted by TNS to specify the maximum length of devicename.
  • the data marshaller takes into account the data length parameter or symbol when arranging data so that it can be sent out in a message.
  • the client marshals the data.
  • Marshalling involves locating the memory locations of the data and storing those locations and lengths into an array that is then used to write the data to the outgoing message stream. This allows generic access to the data locations without having to copy memory.
  • the first step of this process is to directly capture the parameters and the addresses of these parameters into an array. This orders the parameters and avoids needless memory copies. Each parameter is recorded into this array (called an "io vector"). Once this has occurred, then the system iterates through each parameter, and the ones that represent variable length data are then processed so that their length can be obtained and added to this io-vector. An io-vector for sending data and an io-vector for the reception of reply or response data are both created. The variable length data and parameters that are pointers or references are stored on this reply io-vector.
  • the reply data may contain changes to the reference and variable length data.
  • the pointer values in the parameters will be invalid, and have to be restored to the memory locations as known by the client. This restitution of correct data pointers occurs after the call.
  • the client and the server resolve variable length data pointers in different ways.
  • the client has to specify a buffer with the correct length of the data to be returned before making the remote call.
  • the server knows how much data is transferred at the time of message reception.
  • the call is made on the server but the server will return an error indicating that the reply buffer is insufficient in length to store the reply. For variable length data, the required length is returned in the corresponding data length parameter. The client can then adjust the length of the buffer and make the call again.
  • the client uses hints returned by the server to know where the variable length data is located in the reply buffer.
  • Hints include null terminated data and fixed sized data that indicate data lengths. Those hints are used to update the references or pointers in the parameter list. Once the update occurs, the data can be accessed without being copied from the reply buffer.
  • the server does not need to pre allocate a buffer to read variable length data. It can grow its buffer and read the data after the message is received. It operates similarly to the client by using hints to understand where variable length data begins and ends.
  • the hints used by the server are the same as for clients. Those hints are used to populate the references and pointers with values that directly reference the buffer used to receive the data.
  • TNS Clients and Servers seamlessly use the network communication mechanism provided by the operating system platform. In this way clients and servers do not have to be located on the same physical computer. TNS does not need a network protocol to handle the information exchanged between them if this is not desired. TNS can use any level of communication, from high level to On the wire' transactions.
  • a server starts and after it has initialized, it makes itself available for clients to find it and connect to it. This can be done in numerous ways that are well known in the art.
  • the client starts it can be given a hint as to how to contact the server or it can be designed to scan for the server. Again, this can be implemented in numerous ways that are well known in the art and is no specific implementation is required for TNS.
  • TNS based servers keep track of the clients that have connected to it. This allows the implementer to enforce access permissions and allow the server to ignore requests from unauthorized clients. Additionally, encryption schemes can be implemented to encrypt the data in the call. Keeping track of clients allows TNS to optionally associate instances of classes with specific clients. This prevents clients from accessing and manipulating class instances owned by other clients. When a client disconnects, the TNS server can optionally clean up the instances that it has created on behalf of the client.
  • Workstation 500 may be any of the above described engines, workstations, servers, or the like.
  • the workstation 500 is shown as a single, contained unit, such as, for example, a desktop, laptop, tablet, handheld, smart phone, personal digital assistant, or mobile processor, but the workstation 500 may comprise portions that are remote and connectable via a network connection such as via a LAN, a WAN, a WLAN, a WiFi Network, Internet, or the like.
  • the workstation 500 includes a processor 502, a system memory 504, and a system bus 506.
  • the system bus 506 which may follow any conventional protocol such as, for example, PCI or PCI-express, couples the various system components and allows data and control signals to be exchanged between the components.
  • the system memory 504 generally comprises both a random access memory (RAM) 508 and a read only memory (ROM) 510.
  • the ROM 510 generally stores a basic operating information system such as a basic input/output system (BIOS) 512.
  • the RAM 508 often contains the basic operating system (OS) 514, application software 516 and 518, and data 520.
  • the system memory 504 contains the code for executing the functions and processing the data as described herein to allow the present technology of the present application to function as described.
  • the workstation 500 generally includes one or more of a hard disk drive 522 (which also includes flash drives, solid state drives, etc. as well as other volatile and non-volatile memory configurations), a magnetic disk drive 524, or an optical disk drive 526.
  • the drives are connected to the bus 506 via a hard disk drive interface 528, a magnetic disk drive interface 530 and an optical disk drive interface 532.
  • Application modules and data may be stored on a disk, such as, for example, a hard disk installed in the hard disk drive (not shown).
  • the workstation 500 has network connection 534 to connect to a local area network (LAN), a wireless network, an Ethernet, the Internet, or the like, as well as one or more serial port interfaces 536 to connect to peripherals, such as a mouse, keyboard, microphone, touch screen, light pen, modem, or printer.
  • the workstation 500 also may have USB ports or wireless components not shown.
  • Workstation 500 typically has a display or monitor 538 connected to bus 506 through an appropriate interface, such as a video adapter 540. Monitor 538 may be used as an input mechanism using a touch screen, a light pen, or the like.
  • DSP Digital Signal Processor
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • a general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
  • This macro is used to describe a datatype to the TNS reflection subsystem. It is normally
  • TNS_REFLECT TYPE
  • TNSTypeDefTHelper TYPE>
  • TNSTypeDefTHelper TYPE> : s_createStaticTNSTypeDefT (#TYPE)
  • TNS REFLECT_DERIVED #define TNS_REFLECT_DERIVED ( TYPE, DERIVED ) template ⁇ > TNSTypeDefDerivedTHelper ⁇ TYPE, DERIVED>
  • This macro is used to describe a datatype to the TNS reflection subsystem. It is normally
  • TNS_REFLECT will result in a compiler error.
  • a nested struct is a
  • This macro is used to deliniate the commencemnt of a nested structure definition.
  • Behavior is undefined if the struct is not a
  • TNSTypeDefT StructType > : : s_typeDef . UpdateName ( #STRUCT, NULL ) ; ⁇
  • TNSTypeDefDerivedTHelper StructType , BaseType> ttddth( #STRUCT, #DERIVED ); ⁇
  • TNSServerHelper : : RegisterStartupHandler
  • TNSServerHelper : : RegisterShutdownHandler
  • This macro defines a member of a struct. It is used for data members only, it cannot
  • TNSTypeDefT typeof ( ⁇ (StructType* ) 10 ) - >MBR ) > : : sGetTypeDef ( ) , #MBR, (uint64_t) offsetof ( StructType, MBR ) ),
  • This macro defines a member of a struct that is a pointer to data for TNS reflection. It provides a way to
  • TNS_REFLECT_STRUCT_MEMBER_PTR MBR, LENMBR
  • TNSSymbolDef TNSTypeDefT ⁇ typeof ( ( (StructType*) 10) ->MBR ) > : : sGetTypeDef ( ) , #MBR, (uint64_t) offsetof ( StructType, LENMBR ) ),
  • TNS_REFLECT_CLASS_CONSTRUCTOR CONSTR
  • TNSSymbolDef &TNSTypeDef ⁇ typeof ( StructType :: CONSTR )* > : : s_typeDef , #CONSTR ), #endif
  • TNSTypeDefT StructType> : : s_typeDef .UpdateName ( name, members ); ⁇
  • TNSTypeDefT ⁇ StructType> : : s_typeDef .UpdateName ( name, members ) ; ⁇
  • TNSTypeDefT StructType> : : s_typeDef . UpdateName ( name, members ) ; ⁇
  • TNSTypeDefT StructType> : : s_typeDef . UpdateName ( name, members ) ; ⁇
  • TNSTypeDefT StructType> : : s_typeDef . UpdateName ( name, members ); ⁇
  • TNSTypeDefT ⁇ StructType> : : s_typeDef .UpdateName ( name, members ) ; ⁇
  • TNSTypeDefT ⁇ StructType> : : s_typeDef .UpdateName ( name, members ) ; ⁇
  • TNSTypeDefT StructType> : : s_typeDef . UpdateName ( name, members ) ; ⁇
  • TNSTypeDefT StructType> : : s_typeDef . UpdateName ( name, members ) ; ⁇
  • TNS_STATIC_METHOD METHOD, METHODPROTO
  • TNS_VIRTUAL_METHOD METHOD, METHODPROTO
  • TNS_STATIC_METHOD METHOD, METHODPROTO
  • TNS_STATIC_METHOD public: static METHODPROTO;
  • TNS_VIRTUAL_METHOD public: virtual METHODPROTO;
  • TNS_STATIC_METHOD public: static METHODPROTO;
  • TNS_VIRTUAL_METHOD public: virtual METHODPROTO;
  • TNS_STATIC_METHOD METHOD, METHODPROTO
  • TNS_VIRTUAL_METHOD METHOD, METHODPROTO
  • TNS_STARTUPMETHOD TNS_STARTUPMETHOD
  • TNS_BEGIN_CLASS_DERIVE CLASS_NAME, DERIVED_ ftdefine TNS_CONSTRUCTOR ( CONPROTO )
  • TNS_STATIC_METHOD METHOD, METHODPROTO
  • TNS_VIRTUAL_METHOD METHOD, METHODPROTO
  • TNS_STARTUPMETHOD TNS_STARTUPMETHOD
  • TNS_BEGIN_CLASS_DERIVE CLASS_NAME, DERIVED_NAME ftdefine TNS_CONSTRUCTOR ( CONPROTO )
  • TNS_STATIC_METHOD METHOD, METHODPROTO
  • TNS_VIRTUAL_METHOD METHOD, METHODPROTO
  • TNS_STARTUPMETHOD TNS_STARTUPMETHOD

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)
  • Control By Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention se rapporte à un système de substrat-réseau transparent comprenant au moins un module serveur et au moins un module client. Le module serveur exécute une fonctionnalité sélectionnée, comme le déplacement d'un actionneur, une opération mathématique et la réception des données en provenance d'un capteur. Au moment de l'exécution, le code machine du module serveur écrit des informations nécessaires pour décrire la fonctionnalité sélectionnée dans une mémoire. Les informations écrites dans la mémoire contiennent des informations nécessaires pour invoquer la fonctionnalité du module serveur et peuvent comprendre des types, des éléments et des paramètres. Le module client recherche la fonctionnalité sélectionnée dans la mémoire, demande des informations au module serveur et invoque la fonctionnalité du module serveur. Une fois la fonctionnalité invoquée par le client, le module serveur utilise les informations contenues dans la mémoire pour créer des appels de fonction dynamiques.
PCT/US2010/003165 2009-12-11 2010-12-13 Système de substrat-réseau transparent WO2011071543A2 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CA2783829A CA2783829C (fr) 2009-12-11 2010-12-13 Systeme de substrat-reseau transparent
US13/514,329 US9135055B2 (en) 2009-12-11 2010-12-13 Transparent network substrate system
BR112012013808-1A BR112012013808B1 (pt) 2009-12-11 2010-12-13 sistema de rede para rede transparente
US14/853,820 US9672014B2 (en) 2009-12-11 2015-09-14 Transparent network substrate system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US28590509P 2009-12-11 2009-12-11
US61/285,905 2009-12-11

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/514,329 A-371-Of-International US9135055B2 (en) 2009-12-11 2010-12-13 Transparent network substrate system
US14/853,820 Continuation US9672014B2 (en) 2009-12-11 2015-09-14 Transparent network substrate system

Publications (2)

Publication Number Publication Date
WO2011071543A2 true WO2011071543A2 (fr) 2011-06-16
WO2011071543A3 WO2011071543A3 (fr) 2011-11-24

Family

ID=44146101

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2010/003165 WO2011071543A2 (fr) 2009-12-11 2010-12-13 Système de substrat-réseau transparent

Country Status (4)

Country Link
US (2) US9135055B2 (fr)
BR (1) BR112012013808B1 (fr)
CA (1) CA2783829C (fr)
WO (1) WO2011071543A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013144758A1 (fr) 2012-03-27 2013-10-03 Novartis Ag Traitement de la fibrose

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3543813A1 (fr) * 2018-03-19 2019-09-25 CODESYS Holding GmbH Architecture serveur-client pour réseau de commande industriel
CN111124495B (zh) * 2019-12-16 2021-02-12 海光信息技术股份有限公司 一种数据处理方法、解码电路及处理器

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020059470A1 (en) * 1996-11-27 2002-05-16 Microsoft Corporation Method and system for invoking methods of objects over the internet
US20040148338A1 (en) * 2001-11-16 2004-07-29 John Saare Method and system for an extensible client specific address book application in a portal server
US20060136351A1 (en) * 2004-12-08 2006-06-22 Rohan Angrish Techniques for automatically exposing, as web services, procedures and functions stored in a database
US20080071884A1 (en) * 2006-09-15 2008-03-20 Emc Corporation Protecting client-side code

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020073246A1 (en) * 1998-06-29 2002-06-13 Stephen F.B. Pickett Code server
US5649204A (en) * 1991-08-22 1997-07-15 Rec Software, Inc. Method and apparatus for consolidating software module linkage information used for starting a multi-module program
US7870535B2 (en) * 2001-02-22 2011-01-11 Accenture Global Services Gmbh Distributed development environment for building internet applications by developers at remote locations
US20030163450A1 (en) * 2001-05-25 2003-08-28 Joram Borenstein Brokering semantics between web services
US7640153B2 (en) * 2001-06-04 2009-12-29 Hewlett-Packard Development Company, L.P. Networked client-server architecture for transparently transforming and executing applications
US7493397B1 (en) * 2001-06-06 2009-02-17 Microsoft Corporation Providing remote processing services over a distributed communications network
US7412057B2 (en) * 2002-05-31 2008-08-12 Intel Corporation Fast-software-implemented pseudo-random code generator
US7406481B2 (en) * 2002-12-17 2008-07-29 Oracle International Corporation Using direct memory access for performing database operations between two or more machines
US20050251527A1 (en) * 2004-05-07 2005-11-10 Mark Phillips System and method for integrating disparate data and application sources using a web services orchestration platform with business process execution language (BPEL)
US8365153B2 (en) * 2007-10-26 2013-01-29 Qualcomm Incorporated Server-based code compilation

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020059470A1 (en) * 1996-11-27 2002-05-16 Microsoft Corporation Method and system for invoking methods of objects over the internet
US20040148338A1 (en) * 2001-11-16 2004-07-29 John Saare Method and system for an extensible client specific address book application in a portal server
US20060136351A1 (en) * 2004-12-08 2006-06-22 Rohan Angrish Techniques for automatically exposing, as web services, procedures and functions stored in a database
US20080071884A1 (en) * 2006-09-15 2008-03-20 Emc Corporation Protecting client-side code

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RAJKUMAR, R. ET AL.: 'the real-time publisher/subscriber inter-porcess communi cation model for distributed real-tiem systems: design and implementation' THE 1ST IEEE REAL-TIME TECHNOLOGY AND APPLICATIONS SYSMPOSIUM, MAY 15-17 91995 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013144758A1 (fr) 2012-03-27 2013-10-03 Novartis Ag Traitement de la fibrose

Also Published As

Publication number Publication date
CA2783829A1 (fr) 2011-06-16
US9135055B2 (en) 2015-09-15
BR112012013808B1 (pt) 2021-02-09
CA2783829C (fr) 2018-07-31
US9672014B2 (en) 2017-06-06
WO2011071543A3 (fr) 2011-11-24
US20120323994A1 (en) 2012-12-20
BR112012013808A2 (pt) 2018-05-29
US20160077813A1 (en) 2016-03-17

Similar Documents

Publication Publication Date Title
Schmidt et al. Pattern-oriented software architecture, patterns for concurrent and networked objects
US9086924B2 (en) Executing a distributed java application on a plurality of compute nodes
CN106415495B (zh) 用于应用开发的编程系统和语言
JP4684376B2 (ja) カーネル・モードにおけるソフトウェア・ドライバを相互接続する方法，コンピュータ・プログラム・プロダクト、システムおよび記録媒体
JP2978807B2 (ja) 遠隔プロシージャ・コール・システムおよび方法
US6951021B1 (en) System and method for server-side communication support in a distributed computing environment
US8281311B2 (en) Executing a distributed software application on a plurality of compute nodes according to a compilation history
US6947965B2 (en) System and method for communications in a distributed computing environment
US8359570B2 (en) Adaptive scripting tool
CN100462921C (zh) 用于简档形成接口辅助类加载的方法和系统
US9235495B2 (en) Method and system that provides an interactive debugging session
Casey et al. tinyNBI: Distilling an API from essential OpenFlow abstractions
US9672014B2 (en) Transparent network substrate system
US20080040656A1 (en) Instance annotation in object-oriented programming
US20060010421A1 (en) Methods and apparatus for portable object-oriented components
Pase Dynamic probe class library (dpcl): Tutorial and reference guide
US8001523B1 (en) System and methods for implementing an explicit interface member in a computer programming language
Dantam et al. Unix philosophy and the real world: Control software for humanoid robots
Schweigler A unified model for inter-and intra-processor concurrency
CN110018959B (zh) 一种嵌入式应用调试的方法以及系统
Earle et al. Functional Testing of Java Programs
Lentini et al. Implementation and analysis of the user direct access programming library
Elde InfiniBand RDMA over PCI Express Networks
Fuad An autonomic software architecture for distributed applications
Starkman The Robot Operating System in Transition: Experiments and Tutorials

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10836327

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2783829

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13514329

Country of ref document: US

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112012013808

Country of ref document: BR

122 Ep: pct application non-entry in european phase

Ref document number: 10836327

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase

Ref document number: 112012013808

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20120608