Pre-scanner for inspecting network traffic for computer viruses

In one embodiment, an add-on pre-scanner card is removably pluggable into a local bus of a computer. The add-on pre-scanner card may be coupled to a computer network to receive network traffic. The add-on pre-scanner card may be configured to extract payloads from received packets and scan the payloads for computer viruses. The add-on pre-scanner card may pass scanned payloads and other data to the computer by way of a shared memory interface. The pre-scanner card may identify each payload as infected with a virus, virus-free, or unknown to allow the computer to distinguish payloads that do not need further scanning from those that do. The computer may further scan for viruses payloads that the pre-scanner card cannot ascertain as either virus free or virus infected.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to computer networks, and more particularly but not exclusively to network security apparatus.

2. Description of the Background Art

Computer viruses, worms, Trojans, and spyware are examples of malicious codes that have plagued computer systems throughout the world. Although there are technical differences between each type of malicious code, malicious codes are collectively referred to herein as “viruses” for ease of illustration and compliance with common usage.

The Internet and similar public networks enable viruses to spread quickly to infect a large number of computers. As a precautionary measure against viruses, private computer networks may deploy a virus scanner between its computers and the Internet. Currently available in-line virus scanners perform either store-scan-forward scanning or stream scanning. Store-scan-forward scanning is typically implemented in software using a complex file-based scanner. A complex file-based scanner stores received incoming data, waits to receive all of the data comprising a file, scans the file for viruses once all of its data are received, and forwards the data to its destination assuming no viruses are found in the file. Being implemented in software, store-scan-forward scanning provides great flexibility, is easily extensible, allows for high virus detection rate with relatively low false positives (i.e., erroneous detection of a virus) and low false negatives (i.e., failure to identify a virus). However, relying on a software implementation yields relatively slow performance, resulting in excessive, sometimes unacceptable, processing delays.

Stream scanning, also referred to as “cut-through” scanning, receives, scans, and forwards data on non-file data units, typically on packet levels. Scanning commences as soon as a number of data units become available, and scanned data units are immediately forwarded out to their destination assuming no viruses are found. This way, data receiving, scanning, and forwarding occur concurrently, allowing for faster throughput compared to store-scan-forward scanning. Stream scanning, whether implemented in hardware or software, provides performance advantage that is noticeable by the end-user. However, stream scanning has relatively low virus detection capability because only forward scanning is possible, and has higher rates of false positives and false negatives. In addition, hardware based implementations often rely on less sophisticated scanning algorithms that open up the network to virus attacks.

SUMMARY

In one embodiment, an add-on pre-scanner card is removably pluggable into a local bus of a computer. The add-on pre-scanner card may be coupled to a computer network to receive network traffic. The add-on pre-scanner card may be configured to extract payloads from received packets and scan the payloads for computer viruses. The add-on pre-scanner card may pass scanned payloads and other data to the computer by way of a shared memory interface. The pre-scanner card may identify each payload as infected with a virus, virus-free, or unknown to allow the computer to distinguish payloads that do not need further scanning from those that do. The computer may further scan for viruses payloads that the pre-scanner card cannot ascertain as either virus free or virus infected.

DETAILED DESCRIPTION

FIG. 1Aschematically illustrates an overview of the operation of an add-on pre-scanner card102in accordance with an embodiment of the present invention. In one embodiment, the pre-scanner card102is configured as an intrusive, in-line (also referred to as “bump-in-the-wire”) apparatus for inspecting computer network traffic for viruses. The pre-scanner card102may be configured to receive incoming data and determine whether the data is free of viruses (also referred to as “good data”), infected with one or more viruses (also referred to as “bad data”), or in an unknown state (i.e., the pre-scanner card102cannot determine whether or not the data is infected). The pre-scanner card102may identify good data so that a back-end complex scanner100does not have to scan that data for viruses, reducing its virus scanning workload. In the example ofFIG. 1A, the pre-scanner card102in conjunction with the back-end complex scanner100may allow good data from the Internet to enter to the private computer network. The pre-scanner card102may also inspect data passing in the other direction, between two private computer networks, between segments of a private computer network, and so on. The pre-scanner card102in conjunction with the back-end complex scanner100may be configured to block bad data. For example, the pre-scanner card102may drop or quarantine bad data. Notification of the blocking may be passed to the back-end complex scanner100for logging and reporting purposes.

In the example ofFIG. 1A, data in the unknown state is passed to a back-end complex scanner100for second level scanning. The back-end complex scanner100may comprise a general purpose computer, such as a server or desktop computer with a local bus, with a file-based scan engine101. The file-based scan engine101is preferably implemented as software stored in computer memory and executed by the processor of the back-end scanner100. The file-based scan engine101may be a conventional file-based antivirus scan engine, such as those from antivirus vendors including Trend Micro, Inc. The file-based scan engine101allows for more comprehensive virus scanning at the expense of performance. However, the pre-processing performed on incoming data by the pre-scanner card102minimizes the virus scanning workload of the file-based scan engine101. Using a file-based scan engine101to perform comprehensive virus scanning simplifies the design and implementation of the scan engine of the pre-scanner card102, allowing the pre-scanner card102to operate faster.

Generally speaking, the pre-scanner card102and a back-end complex scanner100together performs a two-level virus scanning, with the pre-scanner card102performing a first level virus scanning of incoming data on a packet level and the back-end complex scanner100performing a second level virus scanning of the incoming data on a file-level in the event the pre-scanner card102cannot determine whether or not the incoming data is infected by a virus. This two-level virus scanning approach allows for the reduced latency and higher performance of hardware-based stream scanners with the accuracy and flexibility of software-based store-scan-forward scanners.

The pre-scanner card102is an “add-on” card in that it is configured to be removably plugged into a bus of a general purpose computer. For example, the pre-scanner card102may be readily installed in a computer by inserting the pre-scanner card102into a slot or terminal of a local bus of the computer; the pre-scanner card102may also be removed from the local bus by simply lifting it from the slot or terminal.

While the pre-scanner card102may be effectively integrated with a back-end complex scanner100in the same motherboard, implementing it as an add-on card provides several advantages heretofore unrealized. First, the pre-scanner card102may be readily installed in existing customer computers. Second, antivirus vendors may readily integrate the operation of the pre-scanner card102with file-based virus scanners in current customer installations by adding interfacing software modules. Third, the use of an add-on card rather than a dedicated appliance allows existing customers to migrate for improved performance incrementally and at reasonable cost. Fourth, the pre-scanner card102may be moved to faster computers as they become available. Fifth, upgrading the pre-scanner card102with newer versions only requires removal of the old add-on card and installing the new one in its place in the same computer.

In one embodiment, the pre-scanner card102comprises a PCI (Peripheral Component Interconnect) card pluggable into a PCI local bus. Other buses may also be employed without detracting from the merits of the present invention. The pre-scanner card102may be installed in an available bus slot or terminal of a back-end complex scanner100, for example. In other embodiments, the pre-scanner card102may be integrated with the motherboard of the back-end complex scanner100.

FIG. 1Bschematically illustrates another configuration where an add-on pre-scanner card102passes unknown data to either of two back-end complex scanners100(i.e.,100-1,100-2) in accordance with an embodiment of the present invention. The configuration ofFIG. 1Bincreases the throughput of the pre-scanner card102by offloading file-based virus scanning to one of two back-end complex scanners100.

FIG. 1Cschematically illustrates another configuration where an add-on pre-scanner card102is configured to pass unknown data to one of multiple two back-end complex scanners100in accordance with an embodiment of the present invention. The configuration ofFIG. 1Cfurther increases the throughput of the pre-scanner card102by offloading file-based virus scanning to one of several back-end complex scanners100.

In the example ofFIG. 1C, a switch103allows unknown data to be passed to other back-end complex scanners100coupled to the switch.FIG. 2schematically shows an add-on pre-scanner card102in accordance with an embodiment of the present invention. Note that not all connections are shown inFIG. 2for clarity of illustration. In one embodiment, the pre-scanner card102operates on TCP (transmission control protocol) packets. The pre-scanner card102may pre-scan incoming TCP packets to classify them as good (i.e., virus free), bad (i.e., virus infected), or unknown (i.e., cannot determine whether infected or not). Unknown packets are sent to a back-end complex scanner100for more comprehensive virus scanning by a file-based scan engine101. This reduces the scanning load of the back-end complex scanner100without compromising detection accuracy. Data and summary information for good data may be passed to the back-end complex scanner100in order to perform additional checks on the data, such as to check if an email has content characteristic of SPAM or to verify the digital signatures of ActiveX controls. The pre-scanner card102may also perform control, normalization, and support functions to off-load these functions from the back-end complex scanner100for even more performance gains.

In the example ofFIG. 2, the pre-scanner card102includes a network termination block211and a network interface212to send (see arrow202) and receive (see arrow201) TCP packets to and from a gigabit computer network. The network termination block211may comprise one or more terminals for plugging network communication cables to the pre-scanner card102. The network interface212may comprise a network interface chip, such as the Intel® IXF 1002 Dual-Port Gigabit Ethernet MAC, MAC-1G1 Gigabit Ethernet Media Access Controller Core from Evatronix of Poland, MorethanIP GmbH of Germany or equivalent soft core from other IP vendors.

The pre-scanner card102may include programmable logic220, which may comprise one or more ASIC (application-specific integrated circuit) or FPGA (Field Programmable Gate Array) devices. The programmable logic220may include a packet routing and holding area221, a packet pre-processing module223, a control module222, a normalization and support module224, a scan engine225, a packet header and checker/TCP processor module227, timers228, and a manager226.

The packet routing and holding area221may comprise a limited amount of data storage locations configured to provide buffering for down-stream processing delays. Received packets sit in the packet routing and holding area221until the next packet arrives. A packet currently in the packet routing and holding area221is also referred to herein as “current packet.” The pre-scanner card102may perform one of the following actions depending on the next arriving packet:If the next arriving packet is of the same flow (as indicated by packet pre-processing module223) as the current packet and not the last packet (based on arriving state and not the sequential number), the current packet is immediately transmitted out back to the network.If the next arriving packet is the last packet and is of the same flow as the current packet, the pre-scanner card102waits for a forward or drop command from the back-end complex scanner100, which is routed through the scan engine225(see arrow243).If the next arriving packet is not of the same flow as the current packet, then the current packet is swapped out to the packet buffer232, making space in the packet holding and routing area221for the next arriving packet. The previously current packet may be swapped back from the packet buffer232to the packet holding and routing area221as required.

The packet pre-processing module223may be configured to strip header and payload from packets, tag payloads with flow tags, and forward payloads to corresponding protocol analyzers in the control module222. In one embodiment, the pre-processing module223also receives current packets sitting in the packet holding and routing area221. The packet pre-processing module223does not have to receive the complete set of packets of a particular flow to operate on current packets.

The packet pre-processing module223may forward current packets to the TCP processor of the module221for validation and to classify them as part of a packet flow. As can be appreciated, a packet flow may comprise a plurality of packets associated with a particular TCP connection.

The packet pre-processing module223may create and attach a flow tag to each packet payload. Flow tags may be used to determine which payload goes with which packet flow. A flow tag may include VLAN (virtual local area network) information, packet sequential number, summary of packet header information (e.g., source and destination IP addresses and port numbers, etc.), and other information. The flow tags may be generated based on packet sequence number or other packet identifier.

The packet pre-processing module223may forward packet headers, payload, and corresponding flow tags to the packet header and checker/TCP processor module227for network security inspection. The module227may consult a header rules library231stored in memory (e.g., SDRAM) coupled to the programmable logic220to determine whether or not a packet is to be dropped and its associated flow blocked. The header rules library231may comprise rules and information on how to identify network security threats. For example, the header rules library231may comprise a listing of IP addresses that are not allowed to traverse the network, rules for authenticating TCP/IP connections, flow tags of packets to be blocked, and so on. As a particular example, the packet pre-processor module223may strip the header of a current packet and pass that header to the module227, where the IP address noted in the header is compared against a list of banned or to be blocked IP addresses listed in the header rules library231. As another example, the module227may use the timers228to detect expired packets and to block packets with particular sequence numbers for a period of time. Once a packet is blocked, packets belonging to the same flow as that packet may also be blocked.

The packet pre-processing module223may determine the communication protocol of the current packet and forward the current packet to the appropriate protocol analyzer in the control module222. For example, the packet pre-processing module may inspect the packet and determine from its destination port number whether it is for SMTP (e.g., port80) or HTTP (e.g., port25).

The control module222may include a protocol analyzer for analyzing packets of particular communication protocols. In the example ofFIG. 2, the control module222includes protocol analyzers for SMTP (simple mail transfer protocol) and HTTP (hyper text transfer protocol). A protocol analyzer may be configured to understand and parse a particular protocol. A protocol analyzer may operate with the normalization and support module224. For example, an email analyzer for SMTP may employ a MIME parser to extract attachments from an email, a decompression engine to decompress archived files, and so on. The control module222may also have an interface for receiving packets for raw files from the packet pre-processing module223. The normalization and support module224may also include a cyclic redundancy check (CRC) engine and an interface to the scan engine225. The CRC engine may be configured to produce a unique numerical fingerprint in the form of a checksum for payloads or other unique piece of data processed by the pre-scanner card102. A scan interface may allow data, such as payloads extracted from current packets, to be forwarded to the scan engine225for virus scanning and forwarding to the back-end complex scanner100.

The manager226may be configured to coordinate the operation of the pre-scanner card102and may provide control and status registers. The manger226may be implemented as a state machine, for example.

The scan engine225may be configured to scan data for computer viruses. In one embodiment, the scan engine225scans data on a packet level. In the example ofFIG. 2, the scan engine225consults the signature database233to determine whether a payload of a particular packet is good, bad, or unknown. The scan engine225may compare the contents of a payload to virus signatures in the database233to determine whether or not the payload is bad (i.e., infected with a virus). If the payload is bad, the scan engine225may indicate in the payload's flow tag that the packet is bad so that the back-end complex scanner100does not have to bother scanning the payload for viruses. This advantageously reduces the virus scanning workload of the back-end complex scanner100. The bad payload may be transmitted to the back-end complex scanner100for logging. Upon finding from the flow tag that the payload is bad, the back-end complex scanner100logs the event and sends a drop command to the packet pre-processing module223to drop the packet carrying the payload. In response, the packet pre-processing module223drops the bad packet and blocks other packets of the same flow.

The scan engine225may also compare the contents of the payload for patterns in the database233indicating that the payload is good (i.e., not infected with a virus). For example, the contents of the payload may not be executable by a processor (e.g., plain text) or does not match one or more sub-patterns that are known to be present in all virus patterns in both the signature database233employed by the scan engine225and the signature database241employed by the file-based scan engine101. In those cases, the scan engine225may deem the payload to be good and accordingly so indicate in the payload's flow tag. The back-end complex scanner100may read the flow tag to determine that the payload is good. Accordingly, the back-end complex scanner100does not have to bother scanning the payload for viruses, reducing its virus scanning workload.

In the event the scan engine225cannot determine whether the payload is good or bad, such as when the contents of the payload match an aggressive signature that is known to have false positives in the signature database233, the payload may be deemed unknown. In that case, the scan engine225may indicate in the payload's flow tag that the payload is unknown before transmitting the payload to the back-end scanner100(see arrow204).

In one embodiment, the scan engine225sends all payloads (i.e., whether good, bar, or unknown) to the back-end complex scanner100for event logging and egress control coordination by way of a local bus. The local bus comprises the PCI-Express bus in one embodiment. The scan engine225may communicate with the back-end complex scanner100by passing data to each other using a shared memory interface on the local bus (seeFIG. 3). The back-end complex scanner100may read the flow tag of a payload to find associated payloads and to determine whether a payload is good, bad, or unknown based on the virus scanning performed by the scan engine225. The back-end complex scanner100may send a packet drop command to the packet pre-processing module223by way of the scan engine225for packets carrying a bad payload.

The back-end complex scanner100may include a file-based scan engine101that consults a signature database341to determine whether or not a file contains a virus. The back-end complex scanner100may use the file-based scan engine101to virus scan payloads that have been tagged by the scan engine225as unknown. In one embodiment, the back-end complex scanner100gathers unknown payloads of the same flow tag to build a logical file. Upon receiving enough payloads to build the logical file, the file-based scan engine101may scan the file for viruses using conventional pattern matching techniques. The file-based scan engine101may compare the contents of the file to those in the signature database241to determine whether or not the file contains a virus. Because the signature database241is more exact (i.e., configured to have more precise patterns) than the signature database233for more complete virus scanning and because the file-based scan engine101has more data to work with (i.e., scans an entire file), the back-end complex scanner100allows for more comprehensive scanning than the scan engine225of the pre-scanner card102. The performance penalty involved with comprehensive scanning in the back-end complex scanner100is minimized by having the pre-scanner card102pre-process the incoming packets to detect readily identifiable bad and good packets.

The back-end complex scanner100may also include other security modules242for URL filtering, certificate validation, IP reputation, anti-phishing, anti-spam, and other conventional network security procedures.

The back-end complex scanner100may send a forward command to the packet pre-processing module223to allow good packets to pass through and propagate back onto the network. The back-end complex scanner100may send a drop command to the packet pre-processing module223to drop and block bad packets.

The pre-scanner card102may be configured to work with more than one back-end complex scanner100. In the example ofFIG. 2, the pre-scanner card102includes an interface244for multiple back-end complex scanners100. The interface244may comprise a PCI-Express over cable interface, commercially available from Texas Instruments, Inc., for example.

In one embodiment, the pre-scanner card102and a back-end complex scanner100communicates to each other by passing messages and data using a shared memory interface.FIG. 3schematically shows the use of a shared memory interface301as a communication channel between the pre-scanner card102and the back-end complex scanner100in accordance with an embodiment of the present invention. The shared memory interface301is preferably located in the local bus (e.g., PCI bus) to readily allow memory space sharing. The shared memory interface may comprise dual ported RAM (DPR) with associated control/contention logic and instruction decoder. The shared memory interface301may have separate address and data lines. The pre-scanner card102and the back-end complex scanner100may pass command, status, payload, and other data to each other by reading and writing to the shared memory interface301. The pre-scanner card102may communicate with the back-end complex scanner100by way of logic through the scan engine225. The shared memory interface301may be physically located separate from or as part of the pre-scanner card102.

FIG. 4schematically shows the architecture of the shared memory interface301in accordance with an embodiment of the present invention. The shared memory interface301may comprise shared memory locations400having portions allocated for sending and receiving messages and portions allocated for sending and receiving segments. In the example ofFIG. 4, the shared memory interface301includes a pair of message rings, a send ring402and a receive ring403, each of which is configured as a circular array of control message buffers and related state machine. The pre-scanner card102and the back-end complex scanner100may periodically poll the send ring402and the receive ring403to determine whether or not data is waiting for them.

The send ring buffer402and the receive ring buffer403may be managed as a generator/consumer queue. The send ring buffer402may be configured for sending messages from the pre-scanner card102to the back-end complex scanner100. For example, the pre-scanner card102may write a message into the send ring402. The back-end complex scanner100may poll the send ring102for new messages and, upon finding the message from the pre-scanner card102, pick-up the message and advance the pointer of the send ring402to the next buffer location. Similarly, the receive ring403may be configured for sending messages from the back-end complex scanner100to the pre-scanner card102. For example, the back-end complex scanner100may write a message into the receive ring403. The pre-scanner card102may poll the receive ring403for new messages and, upon finding the message from the back-end complex scanner100, read the message and advance the pointer of the receive ring403to the next buffer location. The send ring402and the receive ring403may be configured to have enough buffer locations to prevent buffer overrun. The block memory404may comprise blocks of memory locations for storing segments comprising payloads and other data.

FIG. 5schematically shows a message500in accordance with an embodiment of the present invention. A message500may comprise a short control message (e.g., 16 bytes) that may take the form of a command or status. A message500may have message dependent message payloads503and optional fields504. For example, the message payloads503may comprise the operation code for a command (e.g., virus scan an unknown packet) and parameters for the command (e.g., address of a corresponding segment600, as shown inFIG. 6, containing the packet payload). As another example, the message payloads503may comprise processing status (e.g., results of virus scanning).

The transfer of a message500in and out of the shared memory interface301is preferably done using programmed I/O (input output), also referred to as the “PIO method.” In the PIO method, the pre-scanner card102and a back-end complex scanner100reads from or writes into the shared memory interface301by making I/O reads and writes.

Interrupt processing is compute intensive on most operating systems (can consume several thousands CPU cycles) and should be reduced to a minimum. Therefore, per packet interrupts is preferably avoided. This is especially important with high packet arrival rates, as can be expected on a low latency, high speed interconnect. Thus, instead of an interrupt scheme, a polling method to determine whether or not a new message is in the message rings402or403is preferred to reduce latency. In one embodiment, the pre-scanner car102and the back-end complex scanner100poll an empty or full flag501to determine whether or not a message500is empty (does not contain a message) or full (contains a message). The command or status flag502indicates whether or not the message500contains a command or status.

FIG. 6schematically shows a segment600in accordance with an embodiment of the present invention. A segment600may comprise a packet payload to be scanned for viruses and other network security processing and flow tags used to track and identify the packet payload. The packet payload and flow tags may be included in the segment600.

The field601may hold the ID number of a particular back-end complex scanner100in configurations where there the pre-scanner card102works with multiple back-end complex scanners. Using the field601to identify a back-end complex scanner100is simpler but more dynamic than using an existing 32 bit IP address. In implementations where a back-end complex scanner100is hot pluggable, the add-on pre-scanner card102may be configured to assign the ID number of the back-end complex scanner100upon its detection on the local bus. The fields602-605may indicate the ID number of the client in session, the ID of the server in session with the client, the packet number of the session, and the routing segment IP address, respectively. Fields606may contain the payload of the packet in session and other information. A segment600may be configured differently to meet a particular implementation without detracting from the merits of the present invention.

The size of a segment600may be equal to the size of a flow tag plus the largest Ethernet packet size. Preferably, segments600may be linked together to form larger packet payloads, such as those required for jumbo packets (e.g., 9 Kbytes). For example, a first segment600may hold the flow tag and the following linked segments600may be configured as pure data buffers holding the jumbo packet payload.

Even though the shared memory interface301is configured as full duplex to allow either the pre-scanner card102or a back-end complex scanner100to access messages500in the message rings402and403, transfer of segments600is preferably simplex. In one embodiment, a segment600is always transferred from the pre-scanner card102to the shared memory interface301and then to a back-end complex scanner100. The transfer of segments600from the shared memory interface301may be by direct memory access (DMA) to aligned page frames of main memory in the back-end complex scanner100allocated by a device driver701(seeFIG. 7) from a virtual memory page pool.

In one embodiment, the pre-scanner card102and a back-end complex scanner100communicate using a client-server model, with the pre-scanner card102working as a client and the back-end complex scanner100working as a server. A back-end complex scanner100may be viewed as a slave entity, waiting and interpreting commands from the pre-scanner card102. Commands from the pre-scanner102and responses from the back-end complex scanner100may comprise messages500posted in the shared memory interface301.

FIG. 7schematically illustrates the software interface between an add-on pre-scanner card102and a back-end complex scanner100in accordance with an embodiment of the present invention. In the example ofFIG. 7, the pre-scanner card102is removably plugged (i.e., can be readily removed and installed) in the local bus of the back-end complex scanner100. The shared memory interface301may be a separate memory card also removably plugged into the same local bus. The components701-707are components of the back-end complex scanner100.

For example, an application702may send data to an Ethernet card707by making a conventional call that flows through the interface library703, winsock library704, transport driver interface (TDI) driver705, and network device interface (NDIS) driver706. In contrast, the application702running in the back-end complex scanner100may communicate with the pre-scanner card102by way of an application level socket interface implemented using I/O Completion Ports (IOCP). Such implementation provides an industry standard API (application programming interface) to a programmer, thus simplifying software development, updates, and maintenance cycles.

Generally speaking, sockets implementation is located in the operating system kernel. Thus, every socket operation involves a transition into the kernel and back, which is very expensive in terms of latency. Invoking driver-supported kernel entry point costs thousands of CPU cycles. Decoupling of the kernel-based device driver701from the application code is achieved using the shared memory interface301, which is accessible by either the pre-scanner card102or the back-end complex scanner100. Using this method, kernel calls are avoided in the predominant code path of the sockets implementation. In the example ofFIG. 7, a kernel component in the form of the device driver701sets up shared memory mapping. However, the kernel is not involved during the bulk of data transfer between the pre-scanner card102and the back-end complex scanner100.

As shown inFIGS. 1B and 1C, the pre-scanner card102may divide file-based antivirus scanning and other security processing workloads among several back-end complex scanners100. In those cases, the pre-scanner card102divides, maintains, and controls workloads on a per packet flow basis. The connectivity fabric between the back-end complex scanners100and the pre-scanner card102may be created using PCI-Express over cable devices. Generally speaking, PCI-Express over cable is designed to connect modular computers together by use of Cat6 cables or fibers, which are normally used for Gigabit Ethernet connections.

PCI-Express over cable facilitates a remote memory access (RMA) communication model that allows several back-end complex scanners to communicate with the same pre-scanner card102. Remote memory access is a communication model for multipoint servers; it is an excellent connectivity model to achieve zero-copy communication. Remote memory access achieves high performance and lowers latency by overlapping communication and computation. In this model, several back-end complex scanners100remotely access the shared memory interface301by way of the PCI-Express over cable interface coupled to the PCI-Express bus where the shared memory interface301and the pre-scanner card102are installed. In the example ofFIG. 8, the back-end complex scanner100-1accesses the shared memory interface301directly (i.e., in the same computer) over a PCI-Express bus801, while the back-end complex scanners100-2,100-3, and100-4access the shared memory interface301remotely over a PCI-Express bus over cable802. A PCI-Express switch (seeFIG. 1C) may be employed to select particular back-end complex scanners depending on implementation.

A remote memory access model views local or remote nodes as transparent shared memory. Each node can directly access the other node's memory just as easily as its own local memory. In the case of a block move (e.g., transfer of segments600), a node can use its DMA controller to copy a block of memory directly between PCI-Express (local or remote) in a single copy operation with no need for intermediate buffer memories (so called “Zero Copy” operation). This feature greatly reduces latency and lowers overhead of data transfer. The DMA controller may be configured to support both read and write operations and be fully interleaved with remote memory access operations. Using remote memory access achieves zero-copy communication. Zero-copy communication protocols remove memory performance factors from communication performance models and help avoid wasting the valuable and limited memory bandwidth of computing nodes.