Abstract:
A compact, energy-saving and dynamic reconfigurable information processing apparatus achieving high-performance server services for application layers such as databases. Multiple PE matrices are formed in the dynamic reconfigurable processor of an apparatus containing that DRP. A scheduling unit is mounted in the packet I/O for deciding which PE matrix will process subsequent packets while one PE matrix is processing the first packet. When the second packet must be processed based on the same configuration information as the first packet, and the third packet must be processed based on configuration information different from the first packet, the scheduling unit makes the second packet wait until processing of the first packet is complete, and then gives priority to the third packet for processing in the second PE matrix.

Description:
CLAIM OF PRIORITY 
       [0001]    The present application claims priority from Japanese application JP 2007-182205 filed on Jul. 11, 2007, the content of which is hereby incorporated by reference into this application. 
       FIELD OF THE INVENTION 
       [0002]    The present invention relates to technology for providing a server service such as for databases by receiving packets transferred over a network, implementing different processes according to the communication state between the host and the terminal sending or receiving the packets over a network, and changing the data accumulated within the apparatus, or generating new packets and transmitting them outside the apparatus. 
       BACKGROUND OF THE INVENTION 
       [0003]    Parallel advances in ubiquitous computing and the fusion of broadcast and communications have prompted demands from both backend and access users to improve processor performance and provide more diversified services. Meeting these needs requires implementing server services (database: DB) query transactions, anomaly prevention (Internet security), etc.) using ubiquitous devices (Radio Frequency Identification (RFID)/sensors/cameras) on appliances dispersed on edge networks, and improving the response speed and processing performance of the server service. 
         [0004]    The term “appliance” here refers to achieving database and abnormal communication protection (Internet security) functions. 
         [0005]    This anomaly prevention (or Internet security) is the detection and elimination of anomalous packets sent from external attackers. 
         [0006]    The database performs SQL analysis of packets coming in mass quantities from the numerous dispersed RFID/installed sensors/video sensors, data aggregating and updating for the cache, and the automatic cache data uploading for servers. The database also carries out SQL analysis of data request packets such as from client cellular phone terminals, runs XML translations and data downloads from the cache, and automatically downloads the server data to the cache. 
         [0007]    Situations in utilizing the sensors and RFID differ with each user. The contents of the communication packet also differ according to type of sensor/RFID, the application, the installation location, and the time such as day or night. Moreover, the communication state between each terminal sending and receiving packets, differs according to the TCP congestion/transition state, the L (layer) 7 protocol in use, commands in progress, and the progress state of the command in progress. 
         [0008]    The functions required for this appliance therefore differ according to the user/application/location/time and each execution state. The appliances containing these functions must also be dispersed on the edge network to make the processing on small servers or internal boards in communication apparatus efficient. Therefore, besides efficiently processing packets by being compact and energy efficient, the processors for these appliances must also be flexible in handling various processing tasks for individual packets based on the communication state between terminals. 
         [0009]    However, though both flexibility and high-speed processing with a small size and low power consumption are needed, the general-purpose processors and Application Specific Integrated Circuits (ASIC) of the related art have the problem that they lack either flexibility or high-speed processing capability with a compact size and low power consumption. 
         [0010]    The dynamic reconfigurable processor (DRP) on the other hand, contains a processing matrix where numerous processing elements (PE) are connected by a selector. Even at low frequencies the DRP delivers high processing performance at low power consumption by parallel processing. Moreover, the PE connections and processing functions are changed at a minimum of one clock, giving high flexibility by changing the loaded functions within a short time. Multiple processors can therefore execute simple commands in one batch, and combinations of multiple processors can execute complex commands even without raising the operating frequency, so that the parallel processing capability of processing matrix core is enhanced and high processing performance obtained at low power consumption. This DRP can therefore simultaneously process packets at high speed with a compact size and low power consumption, and is also ideal for appliances that must flexibly rewrite algorithms. 
         [0011]    When this DRP is used in equipment offering services for application layers such as databases, the logic loaded in the circuit (generally referred to as “configuration”) must be changed according to the communication state between each host sending and receiving packets (transport layer protocol transition/congestion state, type of application layer protocol, type of command in progress, progress state of command in progress (what extent the file has been sent/received)) and different processing must be executed for each packet. The reconfiguring trigger generated by the processor group within the processing matrix starts changing the configuration. The configuration can therefore be swiftly changed by generating information (communication state of each host sending and receiving the received packet) needed for generating the reconfiguring trigger ahead of time outside the matrix, and by directly inputting it into the processing matrix. 
         [0012]    The present inventors thereupon propose an apparatus with a dynamic reconfigurable processor (DRP) able to reconfigure each packet based on the communication state between the terminal and host (hereafter, generally referred to as “terminal”) (“Query-Transaction Acceleration Appliance with a DRP using Stateful Packet-by-Packet Self-Reconfiguration” IEICE, vol. 107, No. 41, RECONF207-1, PP. 1-6, May 2007). The present invention utilizes direct input/output of communication data that bypasses the memory. Moreover, the present invention achieves high-speed reconfigurations, by changing the configuration that was loaded in the dynamic reconfigurable processor, based on the communication state between terminals generated beforehand outside the processing matrix; and achieves high performance server services of application layers such as databases in a compact and low-power consumption apparatus. 
       SUMMARY OF THE INVENTION 
       [0013]    Problems with an apparatus containing the above dynamic reconfigurable processor (DRP) of the related art with packet reconfiguring capability based on the communication state between terminals are described next while referring to  FIG. 19 . 
         [0014]    This apparatus includes a switch  1901  for switching the packets, a dynamic reconfigurable processor (DRP)  1902  serving as a dynamic reconfiguring unit to execute each arithmetic operation, a packet I/O  1900  for controlling the packet input and output between the switch  1901  and the DRP  1902 , and an external memory  1903  for accumulating all data types. 
         [0015]    The packet I/O  1900  includes a sorter  1904  for sorting the packets received from the switch  1901 , the buffers  1905 ,  1913  for temporarily accumulating the sorted packets, a packet read unit  1906  for reading the packet from the buffer  1905 , a communication state table  1910  for accumulating the communication state, a communication state read unit  1907  for reading the communication state, a communication state update unit  1908  for updating the communication state, a communication state write unit  1909  for writing the communication state, a buffer  1911  for temporarily accumulating the updated communication state, a buffer  1912  for temporarily accumulating the loaded packets, and a cluster unit  1914  for gathering the packets. 
         [0016]    The sorter  1904  sorts the packets  1915  loaded from the switch  1901 , into the packets  1917  requiring processing and, packets  1918  not requiring processing. The packets  1917  requiring processing are accumulated in the buffer  1905 . 
         [0017]    When the processing starts, the packet read unit  1906  reads the packets  1919  accumulated in the buffer  1905 , and transfers them to the communication state read unit  1907 , and communication state update unit  1908 , and the buffer  1912 . 
         [0018]    The communication state read unit  1907  reads the corresponding communication state  1922  from the communication state table  1910  based on the transmit source and destination information recorded in the packet  1920 , and transfers it to the communication state update unit  1908 . 
         [0019]    The communication state update unit  1908  updates the communication state  1948  based on the communication status  1948  received from communication status read unit  1907  and packet  1920  received from the packet read unit  1906 . The updated communication state  1921  and  1949  are transferred to the communication state write unit  1909  and the buffer  1911 . 
         [0020]    The communication state write unit  1909  writes the updated communication state  1921  received from the communication state update unit  1908  as the new communication state  1923 , into the communication state table  1910 . 
         [0021]    The DRP 1902  includes a PE matrix  1927  containing multiple internal processors and, a general-purpose processor  1928 , and configuration data cache  1930 , and an SDRAM I/F 1931  serving as the interface to the external memory, and a bus switch  1929  joining these components. 
         [0022]    The PE matrix  1927  includes a program reconfigurable interrupt generator PE group  1934  for implementing program reconfiguration, an autonomous reconfigurable interrupt generator PE group  1935  for implementing autonomous reconfiguration, a PE group  1936  for implementing L (Layer) 2-7 (mathematical) functions for achieving various functions, and a PE group  1937  for sending TCP-IP checksum calculated packets, and notifying the processing is complete. 
         [0023]    The general-purpose processor  1928  executes the OS  1932  and the reconfiguring function  1933  for performing the processing for reconfiguring. 
         [0024]    After receiving the updated communication state  1949 , from the communication state  1908 , the autonomous reconfigurable interrupt generator PE group  1935  generates an autonomous reconfiguring interrupt  1941 , based on the communication state that was received. 
         [0025]    The configuration data cache (accumulator buffer)  1930  transfers the internally accumulated configuration data to the PE matrix  1927 , based on the autonomous reconfiguring interrupt  1941  that was generated. 
         [0026]    The PE matrix  1927  then reconfigures the wiring and functions of the internal processor units based on the configuration data  1942  from the configuration data cache  1930 . 
         [0027]    After receiving the updated communication state  1949  from the communication state update unit  1908 , the program reconfigurable interrupt generator PE group  1934  generates a program reconfiguring interrupt  1944  for the general-purpose processor  1928  based on the communication state that was received. Moreover, the based on the received communication state  1949 , the configuration data pointer  1938  within the external memory  1903  is rewritten to the address value  1943  where the required configuration data is accumulated. 
         [0028]    When the program reconfiguring interrupt  1944  is received from the program reconfigurable interrupt generator PE group  1934 , the OS  1932  executes the reconfiguring function  1933 . 
         [0029]    The reconfiguring function  1933  loads from the configuration data pointer  1938 , the address values  1946  where the configuration data to be used next is accumulated, and based on these loaded address values  1946 , loads the configuration data  1945  from the configuration data area  1939 . Further, based on this loaded configuration data  1945 , the reconfiguring function  1933  rewrites the configuration data cache to the new configuration data  1947 . Moreover, the reconfiguring function  1933  transfers the rewritten configuration data  1942  to the PE matrix. 
         [0030]    The PE matrix  1927  reconfigures the wiring and function of the internal processor units based on the configuration data  1942  from the configuration data cache  1930 . 
         [0031]    When the configuring of the PE matrix  1927  is completed, the communication state  1924  accumulated in the buffer  1911 , and the packets  1925  accumulated in the buffer  1912  are loaded, and transferred to the PE group  1936  executing the L2-7 function. 
         [0032]    The PE group  1936  executing the L2-7 function executes each type of processing by utilizing the communication state  1924 , the packet  1925 , and the data from the OS/application data area  1940  within the external memory  1903 . The PE group  1936  sends the changed communication state  1926  to the communication state write unit  1909 , and updates the communication state table  1910 . 
         [0033]    After the PE group  1936  executing the L2-7 function has finished the processing, the PE group  1937  calculates the TCP/IP checksum for the newly generated packets, and sends the calculated packets  1951  one after another to the cluster unit  1914 . After all packets are sent, the processing end notification  1950  is sent to the packet read unit  1906 . 
         [0034]    The cluster unit  1914  gathers the packet  1951  from the PE matrix  1927 , and the packets from the buffer  1913 , and outputs them to the switch  1901 . 
         [0035]    After receiving the processing end notification  1950 , the packet read unit  1906  reads (or loads) a new packet from the buffer  1905 . 
         [0036]    The above method achieves a dynamic reconfigurable processor apparatus that reconfigures each packet based on the communication state between terminals. This apparatus utilizes direct input and output of communication data that bypasses the memory. Further, by changing the configuration in the processing matrix within the dynamic reconfigurable processor based on the communication status between hosts generated beforehand outside the processing matrix, the DRP apparatus can change the logic at high speed, and high-performance server services for application layers such as databases achieved in a compact and low-power consumption device. 
         [0037]    However, this dynamic reconfigurable processor apparatus handles the processing in the order that the packets arrive. The configuration data being used is therefore different between prior and latter packets, and if the configuration data for implementing the processing is not accumulated within the configuration data cache  1930 , then a cache miss occurs, creating a time for loading the configuration data from the external memory  1903  into the configuration data cache  1930 . This time causes the problem that a drop in the processing performance occurs. 
         [0038]    Moreover in the above dynamic reconfigurable processor apparatus for reconfiguring each packet based on the communication state between terminals, only describes the case where the DRP  1902  contains one PE matrix  1927 . There is no description of a method for scheduling the allotment of packets to the PE matrix that is required when the DRP  1902  contains multiple PE matrices  1927 . 
         [0039]    The present invention has the object of providing an information processing apparatus and information processing system possessing enhanced processing efficiency, and capable of resolving the above problems in the dynamic reconfigurable processor apparatus for reconfiguring each packet based on the communication state between terminals. 
         [0040]    In order to achieve the above objects, the present invention includes multiple (PE) matrices in the dynamic reconfigurable processor unit, and by utilizing a scheduling unit to allot packets as needed to these processing matrices can suppress cache misses and reduce the time needed to load the configuration data. Moreover, the loading time required for configuration data due to cache misses can be shortened by pre-reading and transferring the configuration data required for processing the second packet in advance, during the processing of the first packet. 
         [0041]    The information processing apparatus of this invention for processing packets sent and received between terminals includes multiple processing matrices in the dynamic reconfigurable processor unit, and a scheduling unit for deciding whether to process the subsequent second and third packets with either the first or the second processing matrix when the first processing matrix is processing the first packet; and when the second packet requires processing based on the same configuration as the first packet and, the third packet requires processing based on configuration information different from the first packet, then the scheduling unit makes the second packet wait until processing of the first packet by the first processing matrix has been completed, and gives the third packet usage priority by the second processing matrix. 
         [0042]    The information processing apparatus of this invention includes a communication state table for storing the communication state between terminals sending and receiving packets, and a packet input/output unit containing a communication state update unit for changing the communication state according to the combinations of internal information for the received packet and the communication state loaded from the communication state table based on the internal information in the packet and, a configuration information accumulator buffer for storing multiple configuration information, and a processor unit group where the function and wiring can be changed; and a processing matrix unit for receiving the packet and the changed communication state and, acquiring configuration information from the configuration information accumulator buffer based on the changed communication state, and reconfiguring the wiring and the processor unit group based on the acquired configuration information, and a dynamic reconfigurable processor unit including processor units for transferring configuration information to the configuration information accumulator buffer, and processing only according to the changed communication state in the packet, and a storage unit for storing multiple configuration information; and the processing units for this dynamic reconfigurable processor unit are configured to allow transferring configuration information based on the second communication state required for processing the subsequent second packet, from the storage unit to the configuration information accumulator buffer, while the processing matrix unit is processing the first packet after reconfiguring it based on the first communication state. 
         [0043]    The information processing system of this invention contains a server, terminals requesting data to the server over a network, and an information processing apparatus for receiving packets transferred between servers and terminals, and executing processing according to the communication state between the terminals and the server sending and receiving packets, and is characterized in that the information processing apparatus includes; a communication state table for storing the communication state between terminals, and a communication state change unit for changing the communication state according to the combinations of internal information for the received packet and the communication state loaded from the communication state table based on the internal information in the packet and, and a first and second processing matrix containing a processing matrix unit group whose wiring and functions can be changed and a configuration information accumulator buffer for storing multiple configuration information for the processing matrix, and further containing a dynamic reconfigurable processor unit for receiving only the packet and changed communication state, and acquiring configuration information from the configuration information accumulator buffer based on the changed communication state and, reconfiguring the wiring and the functions of the processing unit group of the processing matrix based on the acquired configuration information, and a scheduling unit for deciding whether to process packets subsequent to the first packet, with either the first or the second processing matrix, when the first processing matrix is processing the first packet; in an information processing system that executes processing on a dynamic reconfigurable processor unit according to the changed communication state in a packet, and sends those processing results over a network to a server or a terminal. 
         [0044]    The present invention provides an apparatus for improving processing efficiency and achieving high-performance server services for application layers such as databases in a compact, energy-saving and dynamic reconfigurable processing device that reconfigures each packet based on the communication state. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0045]      FIG. 1  is a block diagram showing the memory and dynamic reconfigurable processor and the packet I/O of the first embodiment; 
           [0046]      FIG. 2  is a block diagram showing the information processing apparatus of the first embodiment; 
           [0047]      FIG. 3  is a block diagram showing the dynamic reconfigurable processor of the first embodiment; 
           [0048]      FIG. 4  is a pictorial diagram showing the operation of the dynamic reconfigurable processor of the first embodiment; 
           [0049]      FIG. 5  is a pictorial diagram of the system applied to the first embodiment; 
           [0050]      FIG. 6  is a pictorial diagram of the system applied to the first embodiment; 
           [0051]      FIG. 7  is a drawing for describing the packet data in the first embodiment; 
           [0052]      FIG. 8  is a drawing showing an example of the communication table during processing in the first embodiment; 
           [0053]      FIG. 9  is a drawing showing an example of the communication state table in the first embodiment; 
           [0054]      FIG. 10  is a drawing showing an example of the communication state table during processing in the first embodiment; 
           [0055]      FIG. 11  is a drawing showing an example of a combination of communication states in the first embodiment; 
           [0056]      FIG. 12  is a diagram showing an example of communication state transitions in the first embodiment; 
           [0057]      FIG. 13  is a diagram showing an example of the reconfiguration cycle for configuration data in the first embodiment; 
           [0058]      FIG. 14A  is a flow chart during the configuration data pre-reading and loading in the first embodiment; 
           [0059]      FIG. 14B  is a flow chart showing the transfer of the packet and the changed communication state in the buffer in the first embodiment; 
           [0060]      FIG. 15  is a sequence diagram showing TCP communication control in the first embodiment; 
           [0061]      FIG. 16  is a sequence diagram showing the download to the front end terminal and the device for the server file in the first embodiment; 
           [0062]      FIG. 17  is a sequence diagram showing the registration-updating-selection-deletion of item data of the first embodiment; 
           [0063]      FIG. 18  is a sequence drawing showing the upload to the server for item data of the first embodiment; and 
           [0064]      FIG. 19  is a block diagram of the dynamic reconfigurable processor apparatus utilizing autonomous-reconfiguring of each packet based on the communication state, as a precondition for this invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0065]    The preferred embodiments of the present invention are described next while referring to the drawings. 
       First Embodiment 
       [0066]    The first embodiment of the information processing apparatus is described next.  FIG. 2  is a block diagram showing the structure of the information processing apparatus of the first embodiment. 
         [0067]    An information processing apparatus  200  includes a dynamic reconfigurable processor (DRP)  102  as the dynamic reconfigurable processing unit and, a packet input/output unit (packet I/O)  100 , and a memory  103  as a storage unit, and a network I/F-i (i=1 through N)  203  ( 203 - 1  through  203 -N) and, a communication line connector unit  204  ( 204 - 1  through  204 -N), and a switch  101 . 
         [0068]    This apparatus  200  connects to the network and transfers the ( 210 - 1  through  210 -N) packets received over the network via the network I/F  203 , to the packet I/O  100  or another network I/F  203 . Further, this apparatus  200  sends ( 209 - 1  through  209 -N) the packets from the packet I/O  100  or another network I/F  203  to the network via the network I/F  203 . 
         [0069]      FIG. 3  is a block diagram showing in detail the structure of the dynamic reconfigurable processor (DRP)  102  mounted in the apparatus  200 . 
         [0070]    The dynamic reconfigurable processor  102  includes: a general-purpose processor unit  180  such as an RISC processor, processing matrices (PE matrix# 1 ,  2 )  178 ,  179  each containing multiple compact processor unit whose mutual functions and wiring are variable, a bus switch  193 , configuration data caches (# 1 ,  2 )  195 ,  196  that match the processing matrices  178 ,  179 , a PCI I/F 302  for connecting the PCI bus, and an external memory access SDRAM I/F  194 , a DMA controller  304  for DMA transfer, and other I/F  305  for connecting with other interfaces. The example in this embodiment describes using two processing matrices (PE matrix# 1 ,  2 ) and two configuration data caches (# 1 ,  2 ), however three or more may be used. Note that the processing matrices (PE matrix# 1 ,  2 ) might sometimes be called processing matrix units. 
         [0071]      FIG. 4  is a drawing showing an example of the processing matrices  178 ,  179  in the dynamic reconfigurable processor DRP  102 , changing the configuration  404  through  406  for each of the processing contents  401  through  403 . 
         [0072]    The processing matrices  178 ,  179  contain numerous compact processor units with variable wiring and functions. The processing matrices  178 ,  179  change the configuration  404  through  406  by reconfiguring the functions and wiring of each of the compact processor units according to the processing contents  401  through  403 . This parallel processing achieves high-speed processing performance as well as high flexibility in changing the configuration within a short time. 
         [0073]      FIG. 5  is a pictorial diagram showing an example of using the apparatus  200  of this embodiment on a network. 
         [0074]    An apparatus  200  is installed on an edge network  502  between a back-end system  503  and a front end network  501 . A server  504  and a storage system  505  are installed as the back end terminals in the back end system  503 . Data for processing from the server  504  is accumulated in the storage system  505  ( 522 ). 
         [0075]    When the data-updated packets  508 ,  509 ,  510  arrive from a front-end terminal such as an RFID/fixed sensor/video sensor, the apparatus  200 , changes the data accumulated in the apparatus based on the HTTP/SQL commands recorded in the packet, and returns action instruction packets  511 ,  512  and an update result notification via a format such as HTML/XML. When the data request packet  514  arrives from the portable terminal, the apparatus searches the data accumulated in the apparatus based on the HTTP/SQL commands recorded in the packet, and sends back a request data return packet  515  via a format such as HTML/XML. Also, when an abnormal packet arrives from an attacker, the apparatus decides this is an abnormal communication and discards it ( 507 ) without sending it to the server  504  ( 517 ). Further, the apparatus performs the upload  518 ,  520  to the server, and downloads  519 ,  521  from the server of data accumulated in the apparatus, and keeps the latest version of the accumulated data. 
         [0076]      FIG. 6  shows an example of the back end system used by the information processing apparatus  200  of this embodiment. 
         [0077]    The apparatus  200  is installed in a pre-stage of the server within the back end system  603  or contains the server internally ( 602 ). If the apparatus  200  contains the server, then the switch  101  of the apparatus  200  is connected to the server  212 . 
         [0078]    The operation of the memory  103  and the packet I/O  100  and the dynamic reconfigurable processor  102  of the information processing apparatus  200  of this embodiment are described next. 
         [0079]      FIG. 1  is a block diagram showing in detail a specific example of the memory  103  and the packet I/O  100  and the dynamic reconfigurable processor  102  of the information processing apparatus  200  of this embodiment. 
         [0080]    The packet I/O  100  includes: a sorter unit  104  to decide whether there is a packet for processing or not, and to sort the packet to be processed, and packet buffers # 1  through  4  ( 109 ,  110 ,  111 ,  112 ) for accumulating the sorted packets, and a packet read unit  119  for reading the packets from the packet buffers # 0  through  4 , and a in-process packet count  120  for accumulating a count of packets being processed, and a communication redundancy discriminator  123  for deciding whether a communication is being processed or not, and an in-process communication table  124  for accumulating communications being processed, and a packet buffer # 0  ( 113 ) for re-accumulating the loaded packets when a communication was processed, and an in-process communication recorder unit  128  for recording the in-process communication in the in-process communication table  124 , and a communication state table  132  for accumulating the communication state, and a communication state read unit  131 , and a communication state update unit  136 , and a communication state write unit  138 , and an in-process communication state table  143  for accumulating the communication state matching the packet being processed, and a scheduling unit  142  for scheduling a packet based on the communication state matching the packet being processed, and packet buffers  151 ,  153  for temporarily accumulating the scheduled packet and a communication state matching the packet, and a communication state buffers  150 ,  152 , and data read units (# 1 ,  2 )  158 ,  159  for transferring the communication state and packet at an appropriate timing toward the processing matrices (# 1 ,  2 )  178 ,  179 , and the output packet buffers  170 ,  171  for temporarily accumulating output packets from the PE processing matrices (# 1 ,  2 )  178 ,  179 , and a cluster unit  175  for clustering and outputting the packets. 
         [0081]    The dynamic reconfigurable processor  102  as explained above, includes: a general-purpose processor unit  180 , and processing matrices (PE matrix # 1 ,  2 )  178 ,  179  each containing multiple compact processor unit whose mutual functions and wiring are variable, and configuration data caches (# 1 ,  2 )  195 ,  196 , and a bus switch  193 , and an external memory access SDRAM I/F  194 . 
         [0082]    The external memory  103  contains a configuration data area  103 - 2  for accumulating configuration information that the configuration data caches (# 1 ,  2 )  195 ,  196  cannot hold, and a configuration data pointer a, b, c, d  103 - 1  containing the address pointer to the configuration data within the configuration data area  103 - 2 , and the OS/application data area  103 - 3 . 
         [0083]    The general-purpose processor unit  180  executes the OS  182 . The general-purpose processor unit  180  calls up the reconfiguring function  181  after receiving the reconfiguring trigger generated by the processing matrices (# 1 ,  2 )  178 ,  179 . The reconfiguring function  181  loaded the configuration data from the configuration data area  103 - 2 , loads it into the configuration data caches (# 1 ,  2 )  195 ,  196 , and transfers it to the processing matrix. 
         [0084]    The processing matrices (# 1 ,  2 )  178 ,  179  include: autonomous-reconfiguring interrupt generator PE groups  178 - 2 ,  179 - 2  for generating the autonomous-reconfiguring interrupts based on the communication state, and program reconfiguring interrupt generators PE group  178 - 1 ,  179 - 1  for generating program reconfiguring interrupts  183 ,  186 , an L2-7 function execute PE group  178 - 3 ,  179 - 3  formaking external transmissions and generating new packets and changes in the data accumulated in the memory  103  based on the packet and communication state, and PE groups  178 - 4 ,  179 - 4  for calculating the TCP/IP checksum newly generated by the L2-7 function execute PE group  178 - 3 ,  179 - 3  for sending packets. 
         [0085]    Each unit of the packet I/O, the reconfigurable processor, and the memory  103  are described in detail next. 
         [0086]    When the packets arrive from the switch  101  ( 177 ), the sorter  104  for the packet I/O  100  decides if it is packet for processing or not. If the packet does not require processing then it is output to the cluster unit  175  ( 174 ). If the packet does require processing then it is output to any one of the packet buffers # 1  through  4  ( 109 ,  110 ,  111 ,  112 ) according to the contents recorded in the packet header. 
         [0087]      FIG. 7  is a drawing showing a typical format for the packet  177  that the sorter unit  104  received from the switch  101 . 
         [0088]    The packet  177  contains an InLine  701 , an Outline  702 , an SMAC 703 , a DMAC  704 , a Proto  705 , an SIP  706 , a DIP  707 , a Sport 708 , a Dport  709 , a TCP Flag 710 , a PSEQ 711 , a PACK 712 , an OtherHeader  713 , a (multi-type) command  714 , and a Payload  715 . Further, in this embodiment, the SIP 706 , the DIP 707 , the Sport 708 , and the Dport  709  are collectively referred to as a P.H. (Packet Header)  716 . This P.H.  716  indicates the characteristics of the packet  177 . 
         [0089]    The InLine  701  stores the input line Nos. serving as identification numbers for the lines where the packet is input. The OutLine  702  stores an output line signal serving as an identification signal for lines to output the packet. The SMAC 703  stores the transmit source MAC address serving as the transmit source address for the data link layer. The DMAC 704  stores the destination MAC address serving as the destination address. The Proto 705  stores the network layer protocol. The SIP  706  stores the transmit source address, or in other words, the transmit source IP address serving as the address for the terminal on the transmit side. The DIP 707  stores the destination address, or in other words, the destination IP address serving as the address for the terminal on the receive side. The SPORT 708  stores the transmit source port for the TCP. The DPORT 709  stores the destination port for the TCP. The TCP Flag 710  stores the TCP flag. The PSEQ 711  stores the transmit sequence No. (SEQ No.). The PACK  712  stores the receive sequence No. (ACK No.). The OtherHeader  713  stores the other IP/TCP header data. The (multi-type) command  714  stores the application layer (hierarchy) command. The Payload  715  stores the packet header (Packet Header: P.H.) and data other than for each command. 
         [0090]    The sorter unit  104  for example, sorts the packets according to the contents of the P.H. (Packet Header)  716  namely the packet characteristics, and outputs any of them to the packet buffers # 1  through  4  ( 109  through  112 ) according to the sorting results ( 105  through  108 ). 
         [0091]    The packet read unit  119  reads out (loads) the packet from the packet buffers # 0  through  4  ( 109 - 113 ) when the value of the in-process packet count  120  is smaller than a pre-established value. If packets are accumulated in the packet buffer # 0  ( 113 ), then those packets are given priority in loading (read-out) ( 118 ) from the packet buffer # 0  ( 113 ). If packets are not accumulated in the packet buffer # 0  ( 113 ), then those packets are loaded ( 114  through  117 ) with priority given to packet buffers # 1  through  4  ( 109 - 112 ) having the oldest past loading time. Further, the value of the in-process packet count  120  is increased by 1 ( 121 ). 
         [0092]    When the communication redundancy discriminator  123  receives a packet arrives from the packet read unit  119  ( 122 ), it searches ( 125 ) the in-process communication table  124  for matching in-process communication information ( 125 ) based on the P. H.  176  recorded in the packet. 
         [0093]      FIG. 8  is a drawing showing an example of the in-process communication table  124 . 
         [0094]    The in-process communication table  124  contains m number of communication information entries  801  ( 801 - 1  through  801 - m ) equivalent to the number of communications being processed. 
         [0095]    The entry  801  contains an SIP 802 , DIP 803 , SPORT 804 , DPORT 805 , the same as the above described-P.H. (Packet Header). 
         [0096]    The SIP 802  records the transmit source address for the communication being processed, or in other words the transmit source IP address serving as the address for the host on the transmit side. The DIP  803  records the destination address for the communication being processed, or in other words, the destination IP address serving as the address for the host on the receive side. The SPORT 804  records the TCP transmit source port for the communication being processed. The DPORT 805  records the TCP destination port for the communication being processed. 
         [0097]    The communication redundancy discriminator  123  decides whether or not there is an entry  801  for communication information being processed that matches the P.H.  716  recorded in the packet. If there is a matching entry  801 , then the packet  121  that was loaded (or read out) is transferred ( 126 ) to the packet buffer # 0  ( 113 ). If there is not matching entry, then the loaded packet  122  is transferred ( 127 ) to the in-process communication recorder unit  128 . 
         [0098]    The in-process communication recorder unit  128  records the P.H.  716  written in the packet  127  received from the communication redundancy discriminator  123 , in the in-process communication table  124  as the communication information being processed ( 129 ). The packet  127  received from the communication redundancy discriminator  123  is transferred to the communication state read unit  131 , the communication state update unit  136 , and the scheduling unit  142  ( 130 ,  135 ,  141 ). 
         [0099]    The communication state read unit  131  loads (or reads out) the communication state matching the P.H.  716  listed in the packet, from the communication state table  132  ( 133 ). When there is no communication state in the communication table  132  matching the P.H.  716  listed in the packet, then a new communication state matching the P.H.  716  recorded in the packet is generated. 
         [0100]      FIG. 9  is a drawing showing an example of the communication state table  132 . 
         [0101]    The communication state table  132  includes n number of entries  901  ( 901 - 1  through  901 - n ). 
         [0102]    The entry  901  contains; the F-IP 902 , and the F-PORT 903 , and the F-ID 904 , and the F-SEQ 905 , and the F-ACK 906 , and the F-WIN 907 , and the F-FLIGHT 908 , and the F-TIME 909 , and the F-POINTER 910 , and the F-STATE 911 , and the B-IP 912 , and the B-PORT 913 , and the B-ID 914 , and the B-SEQ 915 , and the B-ACK 916 , and the B-WIN 917 , and the B-FLIGHT 918 , and the B-TIME 919 , and the B-POINTER 920 , and the B-STATE 921 . 
         [0103]    The F-IP 902  records the IP address on the front end side terminal. The B-IP 912  records the IP address on the back end side terminal. The F-PORT 903  records the TCP port No. on the front end side terminal. The B-PORT 913  records the TCP port No. on the back end side terminal. The F-ID 904  records the ID No. for the transmitted packet on the front end side terminal. The B-ID 914  records the ID No. for the transmitted packet on the terminal on the back end side terminal. The F-SEQ 905  records the transmit source sequence No. on the front end side terminal. The B-SEQ 915  records the transmit source sequence No. on the back end side terminal. The F-ACK 906  records the destination sequence No. on the front end side terminal. The B-ACK 916  records the destination sequence No. on the back end side terminal. The F-WIN 907  records the TCP connection congestion control window size of the terminal on the front end side. The B-WIN 917  records the TCP connection congestion control window size of the terminal on the back end side. The F-FLIGHT 908  records the transmitted window size expressing the transmitted data size already in the terminal on the front end side. The B-FLIGHT 918  records the transmitted window size expressing the transmitted data size already in the terminal on the back end side. The F-TIME 909  records the most recent time the packet was received from the terminal on the front end side. The B-TIME 919  records the most recent time the packet was received from the terminal on the back end side. The F-POINTER 910  records the address pointer used by the L2-7 function execute PE group  178 - 3 ,  179 - 3  for executing the different types of processing on the packet received from the terminal on the front end side. The B-POINTER 920  records the address pointer used by the L2-7 function execute PE group  178 - 3 ,  179 - 3  for executing the different types of processing on the packet received from the terminal on the back end side. The F-STATE 911  records the communication state of communications isolated between the apparatus  200  and the front end terminal. The B-STATE 921  records the communication state of communications isolated between the apparatus  200  and the back end terminal. In this embodiment, the F-IP 902 , the B-IP 912 , the F-PORT 903 , and the B-PORT 913  are collectively expressed by the T.H. (Table Header)  922 . 
         [0104]    The F-STATE 911  and the B-STATE 921  for recording the communication states, record values showing any of the combinations shown in  FIG. 11 . The F-STATE 911  and the B-STATE 921  record values showing the start or stop (OPEN/CLOSE)  1120  of the TCP connection, and the establishment or fail of the TCP connection (FULL/HALF)  1121 , and the TCP connection congestion state (Slow Start/Congestion Avoidance (Cong. Avoid.)/Fast Recovery)  1122 , and the presence/absence and type (HTTP/TELNET/FTP)  1123  of application layer protocol  1123 , and the presence/absence of command and variables being executed by the application layer protocol and their type (GET/POST, SELECT/INSERT/DELETE)  1124 , and the (start) or non-termination (Active) or end (Passive)  1125  of the state of the file sent or received during execution of the command. 
         [0105]    The communication state update unit  136  of the packet I/O  100 , changes the communication state based on the communication state  134  received from the communication state read unit  131 , and the packet  135  received from the in-process communication recorder unit  128 . The changed communication state is sent to the communication state write unit  138 , and the scheduling unit  140  ( 137 ,  140 ). 
         [0106]    The communication state write unit  138  writes the changed communication state  137  received from the communication state update unit  136 , into the communication state table  132  ( 139 ). 
         [0107]    The scheduling unit  142  schedules the packet  141  received from the in-process communication recorder unit  128  by comparing the value in the changed communication state  140  received from communication state update unit  136 , with the value recorded in the in-process communication state table  143 . 
         [0108]      FIG. 10  is a drawing showing a typical in-process communication state table  143 . 
         [0109]    The in-process communication state table  143  includes an: INI_POINT (# 1 , 2 ), ( 1003 ,  1008 ), and an END_POINT (# 1 ,  2 ) ( 1004 ,  1009 ), and a CNT (# 1 ,  2 ) ( 1005 ,  1010 ), and a STATE# 1  ( 1002 ) ( 1002 - 1  through  1002 - k ), and a STATE# 2  ( 1007 ) ( 1007 - 1  through  1007 - k ). 
         [0110]    The STATE#L ( 1002 ) records the in-progress communication state in the PE matrix # 1  ( 178 ) and the reconfiguring function  181 . The INI_POINT (# 1 ) ( 1003 ), records the address pointer for STATE# 1  ( 1002 ) for recording the communication state that is currently being processed, in PE matrix # 1  ( 178 ). The END_POINT (# 1 ) ( 1004 ) records the address pointer for the STATE # 1  ( 1002 ) that records the communication state accumulated in the last section of the communication state buffer  152 . The CNT (# 1 )  1005  records the number of communication states currently being processed in the PE matrix # 1  ( 178 ) and the reconfiguring function  181 . 
         [0111]    The STATE# 2  ( 1007 ) records the in-progress communication state in the PE matrix # 2  ( 179 ) and the reconfiguring function  181 . The INI_POINT (# 2 ) ( 1008 ) records the address pointer for STATE# 2  ( 1007 ) for recording the communication state that is currently being processed, in PE matrix # 2  ( 179 ). The END_POINT (# 2 ) ( 1009 ) records the address pointer for the STATE # 2  ( 1007 ) that records the communication state accumulated in the last section of the communication state buffer  150 . The CNT (# 2 )  1010  records the number of communication states currently being processed in the PE matrix # 2  ( 179 ) and the reconfiguring function  181 . 
         [0112]      FIG. 14B  is a flow chart of the operation when the scheduling unit  142  accepts the packet  141  and the changed communication state  140  from the communication state update unit  136  and the in-process communication recorder unit  128 , and transfers them to the buffers  150  through  153  based on the values recorded in the in-process communication state table  143 . 
         [0113]    The scheduling unit  142  loads ( 145 ) the in-process communication state table  143 , and compares the value in the changed communication state  140  received from the communication state update unit  136 , with the communication state STATE# 1  ( 1002 ) recorded in the END_POINT# 1  ( 1004 ) (step  1421 ); and also compares them with the communication state STATE# 2  ( 1007 ) recorded in the END_POINT# 2  ( 1009 ) (step  1422 ). 
         [0114]    If the value in the changed communication state  140  matches the communication state STATE# 1  ( 1002 ) recorded in the END_POINT# 1  ( 1004 ) (YES decision in step  1421 ), then the scheduling unit  142  transfers the changed communication state  140  to the communication state buffer # 1 ( 152 ) ( 148 ). The packet  141  received from the in-process communication recorder unit  128  is transferred ( 149 ) to the packet buffer # 1  ( 153 ) (step  1424 ). Further, the END_POINT# 1  ( 1004 ) is then incremented. However when the communication state recorded in the END_POINT# 1  ( 1004 ) prior to incrementing is STATE# 1  ( 1002 - k ), then the scheduling unit  142  changes the END_POINT# 1  ( 1004 ) to the address value for STATE# 1  ( 1002 ) (step  1425 ). Further, the scheduling unit  142  changes the communication state STATE# 1  ( 1002 ) listed in the changed END_POINT# 1  ( 1004 ) to the value in the changed communication state  140  received from the communication state update unit  136  (step  1426 ). 
         [0115]    If the value of the changed communication state  140  matches the communication STATE# 2  ( 1007 ) recorded in the END_POINT# 2  ( 1009 ) (YES decision in step  1422 ), then the scheduling unit  142  transfers that changed communication state  140  ( 146 ) to the communication state buffer # 2  ( 150 ). Further, the packet  141  received from the in-process communication recorder unit  128  is transferred ( 147 ) to the packet buffer # 2 ( 151 ) (step  1427 ). The END_POINT# 2  ( 1009 ) is incremented. However, when the communication state STATE# 2  ( 1007 - k ) is recorded in the END_POINT# 2  prior to incrementing, then the scheduling unit  142  changes the END_POINT# 2  ( 1009 ) to the address value of STATE# 2  ( 1007 - 1 ) (step  1428 ). Further, the scheduling unit  142  changes the communication state STATE# 2  ( 1007 ) recorded in the changed END_POINT# 2  ( 1009 ) to the value for the changed communication state  140  received from the communication state update unit  136  (step  1429 ). 
         [0116]    When the changed communication state  140  value is different from communication state STATE# 1  ( 1002 ) shown in END_POINT# 1  ( 1004 ), as well as the communication state STATE # 2  ( 1007 ) shown in END_POINT# 2  ( 1009 ), then the scheduling unit  142  compares the CNT (# 1 )  1005  value with the CNT (# 2 )  1010  value (step  1423 ). 
         [0117]    If the CNT (# 1 )  1005  value is smaller than the CNT (# 2 )  1010  value (YES decision in step  1423 ), then the scheduling unit  142  transfers ( 148 ) the changed communication state  140  to the communication state buffer # 1  ( 152 ). The scheduling unit  142  also transfers ( 149 ) the packet  141  received from the in-process communication recorder unit  128  to the packet buffer # 1  ( 153 ) (step  1424 ). The scheduling unit  142  also increments the END_POINT# 1  ( 1004 ). However, when the communication state recorded in the END_POINT# 1  ( 1004 ) before incrementing is STATE# 1  ( 1002 - k ), then the scheduling unit  142  changes the END_POINT# 1  ( 1004 ) to the address value of STATE# 1  ( 1002 - 1 ) (step  1425 ). Further, the scheduling unit  142  changes the communication state STATE# 1  ( 1002 ) recorded in the changed END_POINT# 1  ( 1004 ), to the changed communication state  140  received from the communication state update unit  136  (step  1426 ). 
         [0118]    When the CNT (# 2 )  1010  value is smaller than the CNT (# 1 )  1005  value (NO decision in step  1423 ), the scheduling unit  142  transfers ( 146 ) the changed communication state  140  to the communication state buffer# 2  ( 150 ). The scheduling unit  142  also transfers ( 147 ) the packet  141  received from the in-process communication recorder unit  128 , to the packet buffer# 2  ( 151 ) (step  1427 ). The scheduling unit  142  also increments END_POINT# 2  ( 1009 ). However, when the communication state recorded in the END_POINT# 2  ( 1009 ) before incrementing is STATE# 2  ( 1007 - k ), then the END_POINT# 2  ( 1009 ) is changed to the address value of STATE# 2  ( 1007 - 1 ) (step  1428 ). The scheduling unit  142  also changes the communication state STATE# 2  ( 1007 ) recorded in the changed END_POINT# 2  ( 1009 ) to the value of the changed communication state  140  received from the communication state update unit  136  (step  1429 ). 
         [0119]    In the above described processing by the scheduling unit  142 , when the first processing matrix is processing the first packet, and the second packet requires processing based on the same configuration information as the first packet, and the third packet requires processing based on configuration information different from the first packet, then the second packet is held in standby (made to wait) until the first packet processing in the first processing matrix is completed, and the third packet is given priority for use in the second processing matrix. 
         [0120]    When the data read units (# 1 ,  2 )  159 ,  158  receive the processing end notification ( 165 ,  162 ) from the processing matrices (# 1 ,  2 )  178 ,  179 , the loading of data starts from the communication state buffers (# 1 , 2 )  152 ,  150  and the packet buffers (# 1 ,  2 )  153 ,  151 . 
         [0121]      FIG. 14A  is a flow chart showing the operation when the data read units (# 1 ,  2 )  159 ,  158  are reading (loading) data from the communication state buffers (# 1 , 2 )  152 ,  150  and the packet buffers (# 1 ,  2 )  153 ,  151 . 
         [0122]    When the data read units (# 1 ,  2 )  159 ,  158  receive the processing end notification ( 165 ,  162 ), it decides whether the number of packet awaiting processing or whose processing is in progress but not completed, is 1 or not (step  1401 ). 
         [0123]    In step  1401 , when the number of packets awaiting processing or whose processing is in progress but not completed, is 1, then the data read units (# 1 , 2 ) decide whether or not the number of communication states accumulated in the communication state buffers (# 1 , 2 )  152 ,  150  is 2 or more (step  1402 ). 
         [0124]    In step  1402 , when the number of communication states accumulated in the communication state buffers (# 1 , 2 )  152 ,  150  is less than 2, then the data read units (# 1 , 2 ) decide that the number of communication states accumulated in the communication state buffers (# 1 , 2 )  152 ,  150  is 1 or not (step  1403 ). 
         [0125]    In step  1401 , when the number of packets awaiting processing or whose processing is in progress but not completed is not 1, then the data read units (# 1 , 2 ) decide whether the number of communication states accumulated in the communication state buffers (# 1 , 2 )  152 ,  150  is 0 or not (step  1404 ). 
         [0126]    In step  1402 , when the number of communication states accumulated in the communication state buffers (# 1 , 2 )  152 ,  150  is two or more, then the data read units (# 1 , 2 ) load ( 156 ,  154 ) two communication states from the communication state buffers (# 1 , 2 )  152 ,  150 , and send ( 160 ,  163 ) to the PE matrices (# 1 ,  2 )  178 ,  179  (step  1406 ). After loading, the number of communication states in-progress but not completed is changed to 2. 
         [0127]    After the data read units (# 1 , 2 )  159 ,  158  complete step  1406 , the DRP 102  performs step  1410 . 
         [0128]    In step  1410 , the PE groups  178 - 1 ,  178 - 2 ,  179 - 1 ,  179 - 2  inside the PE matrix (# 1 ,  2 )  178 ,  179  generate the autonomous reconfiguring interrupts  185 ,  188  or the program reconfiguring interrupts  183 ,  186  based on the first communication state that was received, and rewrite the address pointer a,c 103 - 1  for the configuration data determined according to the first communication state ( 184 ,  187 ). Further, the program reconfiguring interrupts  183 ,  186  are generated based on the second communication state that was received, and rewrites the address pointers b, d  103 - 1  for the configuration data according to the second communication state ( 184 ,  187 ). 
         [0129]    If the autonomous reconfiguring interrupts  185 ,  188  were generated then the DRP 102  loads ( 197 ,  198 ) the pre-specified configuration data from the configuration data cache  195 ,  196  to the PE matrix (# 1 , 2 )  178 ,  179  and reconfigures it. After reconfiguring, the DRP 102  loads ( 157 ,  155 ) the first packet matching the first communication state, from the packet buffer (# 1 , 2 )  153 ,  151 , transfers it to the PE group  178 - 3 ,  179 - 3  within the PE matrix (# 1 ,  2 )  178 ,  179  and performs the processing. 
         [0130]    If the program reconfiguring interrupts  183 ,  186  were generated, then the OS 182  accepts the interrupts  183 ,  186 , and calls up the reconfiguring function  181 . 
         [0131]    The reconfiguring function  181  reads the configuration data pointer a through d  103 - 1  ( 190 ), and retrieves the configuration data determined by the configuration data pointer a,c  103 - 1  (specified by first communication state) from the configuration data area  103 - 2  ( 189 ), and loads them into the configuration data cache  195 ,  196  ( 191 ,  192 ). Further, the DRP 102  loads the configuration data loaded from the configuration data caches  195 ,  196 , into the PE matrix (# 1 , 2 )  178 ,  179  ( 197 .,  198 ), and reconfigures them. After reconfiguring, the DRP 102  loads ( 157 ,  155 ) the first packet matching the first communication state from the packet buffer (# 1 , 2 )  153 ,  151 , and transfers ( 161 ,  164 ) it to the PE group  178 - 3 ,  179 - 3  within the PE matrix (# 1 ,  2 )  178 ,  179 , where the processing is performed. 
         [0132]    Also, while the PE group  178 - 3 ,  179 - 3  are processing the first packet, the reconfiguring function  181  pre-reads the configuration data determined by the configuration data pointer b,d 103 - 1  (specified by the second communication state) from the configuration data area  103 - 2  ( 189 ), and loads it into the configuration data caches  195 ,  196  ( 191 ,  192 ). 
         [0133]    The above operation concludes the processing in step  1410 . 
         [0134]    In step  1403 , when the number of communication states accumulated in the communication state buffer (# 1 ,  2 )  152 ,  150  is 1, then one communication state (or state) is loaded ( 156 ,  154 ) from the communication state buffer (# 1 ,  2 )  152 ,  150  and sent ( 160 ,  163 ) to the PE matrix (# 1 , 2 )  178 ,  179  (step  1407 ). After data loading, the data read unit (# 12 )  159 ,  158  changes the number of communication states whose current processing is not completed, to 1. 
         [0135]    In step  1403 , when the number of communication states accumulated in the communication state buffer (# 1 ,  2 )  152 ,  150  is not 1 but is 0; or in step  1404 , when the number of communication states accumulated in the communication state buffer (# 1 ,  2 )  152 ,  150  is 0, then the data read unit (# 12 )  159 ,  158  reads ( 156 ,  154 ) the communication states after accumulating them in the communication state buffer (# 1 ,  2 )  152 ,  150  and sends them ( 160 ,  163 ) to the PE matrix (# 1 , 2 )  178 ,  179  (step  1409 ). After data loading, the data read unit (# 12 )  159 ,  158  changes the number of communication states whose current processing is not completed, to 1. 
         [0136]    After the data loading, the data read unit (# 12 )  159 ,  158  completes the step  1407  or the step  1409 , the DRP 102  performs step  1411 . 
         [0137]    In step  1411 , the PE group  178 - 1 ,  178 - 2 ,  179 - 1 ,  179 - 2  within the PE matrix (# 1 ,  2 )  178 ,  179  generates the autonomous reconfiguring interrupts  185 ,  188  or the program reconfiguring interrupts  183 ,  186  based on the communication states that were received and, rewrites ( 184 ,  187 ) the address pointers a,c  103 - 1  for the configuration data determined according to the communication state. 
         [0138]    If the autonomous reconfiguring interrupts  185 ,  188  were generated, then the data read unit (# 12 ) reads ( 197 ,  198 ) the pre-specified configuration data from the configuration data caches  195 ,  196  to the PE matrix (# 1 ,  2 )  178 ,  179  and that data is reconfigured. After reconfiguring, the packets matching the communication state, are retrieved ( 157 ,  155 ) from the packet buffers (# 1 , 2 )  153 ,  151  and transferred to the PE group  178 - 3 ,  179 - 3  within the PE matrix (# 1 ,  2 )  178 ,  179  ( 161 ,  164 ), and processed. 
         [0139]    If program reconfiguring interrupts  183 ,  186  were generated, then the  0 S 182  accepts the interrupts  183 ,  186 , and calls up the reconfiguring function  181 . 
         [0140]    The reconfiguring function  181  reads ( 190 ) the configuration data pointer a through d  103 - 1  and retrieves ( 189 ) the configuration data determined by the configuration data pointer a,c  103 - 1  from the configuration data area  103 - 2 , and loads ( 191 ,  192 ) them into the configuration data caches  195 ,  196 . The configuration data that was loaded into the configuration data caches  195 ,  196  is further loaded into the PE matrix (# 1 ,  2 )  178 ,  179 , from the configuration data caches  195 ,  196  and reconfiguring performed. After the reconfiguring, the packets matching the communication state are retrieved ( 157 ,  155 ) from the packet buffers (# 1 , 2 )  153 ,  151  and transferred to the PE group  178 - 3 ,  179 - 3  within the PE matrix (# 1 ,  2 )  178 ,  179  ( 161 ,  164 ), and processing performed. 
         [0141]    The above described operation in this way completes the processing in step  1411 . 
         [0142]    In step  1404 , when the number of communication states accumulated in the communication state buffers (# 1 ,  2 )  152 ,  150  is not 0 but is 1 or more, then one communication state is read out ( 156 ,  154 ) from the communication state buffers (# 1 ,  2 )  152 ,  150 , and sent ( 160 ,  163 ) to the PE matrix (# 1 ,  2 )  178 ,  179  (step  1408 ). After retrieving it, the number of communication states whose current processing is not completed is changed to 2. 
         [0143]    After the data read units (# 1 , 2 )  159 ,  158  complete step  1408 , the DRP 102  performs step  1412 . 
         [0144]    In step  1412 , the PE group  178 - 1 ,  178 - 2 ,  179 - 1 ,  179 - 2  within the PE matrix (# 1 ,  2 )  178 ,  179  generates the program reconfiguring interrupts  183 ,  186  based on the received communication state and, rewrites ( 184 ,  187 ) the address pointers b,d  103 - 1  for the configuration data determined according to the connection states. 
         [0145]    If the program reconfiguring interrupts  183 ,  186  were generated then the OS 182  receives the interrupts  183 ,  186 , and calls up the reconfiguring function  181 . 
         [0146]    The reconfiguring function  181  loads ( 197 ,  198 ) the configuration data that was pre-read  189  and loaded  191 ,  192  in step  1410  into the PE matrix (# 1 ,  2 )  178 ,  179 , and performs reconfiguring. After the reconfiguring, the packet matching the previous received communication state is read ( 157 ,  155 ) from the packet buffers (# 1 ,  2 )  153 ,  151 , transferred to the PE group  178 - 3 ,  179 - 4  within the PE matrix (# 1 ,  2 )  178 ,  179 , and processed. 
         [0147]    The reconfiguring function  181  pre-reads ( 189 ) the configuration data set by the configuration data pointer b,d 103 - 1  (specified by newly received communication state) from the configuration data area  103 - 2  while the PE group  178 - 3 ,  179 - 3  is processing the packets matching the received communication state, and loads that data into the configuration data cache  195 ,  196  ( 191 ,  192 ). 
         [0148]    The above operation completes the processing in step  1412 . 
         [0149]    In the processing in steps  1401  through  1412  described above, the processing matrix pre-reads and transfers the configuration information required for processing the second packet from the external memory to the configuration data cached based on the configuration state matching the second packet while the first packet is being processed. 
         [0150]    After completing the processing in steps  1401  through  1412 , the PE groups  178 - 3 ,  178 - 9  perform processing, and outputs the new communication states  166 ,  167  to the communication state write unit  138 . 
         [0151]    The communication state write unit  138  writes ( 139 ) the new communication states  166 ,  167  in the communication state table  132 . 
         [0152]    When the processing in the PE groups  178 - 3 ,  179 - 3  ends, another PE group  178 - 4 ,  179 - 4  calculates the TCP/IP checksum for the newly generated packets, and sends the calculated packets  168 ,  169  one after another to the packet buffers  170 ,  171 . After all the packets are sent, the PE group  178 - 4 ,  179 - 4  sends processing end notifications  165 ,  162  to the data read units (# 1 ,  2 )  159 ,  158 , the scheduling unit  142 , the in-process communication recorder unit  128 , and the packet read unit  119 . 
         [0153]    When the processing end notifications  165 ,  162  arrive, the scheduling unit  142  increments the values in INI_POINT (# 1 , 2 )  1003 ,  1008  by 1, after deleting the in-processing communication states STATE (# 1 ,  2 )  1002 ,  1007  as specified by the INI_POINT (# 1 , 2 )  1003 ,  1008 . However, when the communication state recorded in INI_POINT (# 1 ,  2 )  1003 ,  1008  before incrementing is STATE (# 1 ,  2 )  1002 - k ,  1007 - k , then INI_POINT (# 1 , 2 )  1003 ,  1008  are changed to the address values in STATE(# 1 , 2 )  1002 - 1 ,  1007 - 1 . 
         [0154]    When the processing end notifications  165 ,  162  arrive, the in-process communication recorder unit  128  deletes the lead (beginning) entry  801 - 1 , and rearranges the remaining entries  801  in order starting from the lead entry  801 - 1 . 
         [0155]    When the processing end notifications  165 ,  162  arrive, the packet read unit  119  decrements the value in the in-process packet count  120  by 1. 
         [0156]    Finally, the cluster unit  175  gathers the packets  172 ,  173  read out from the packet buffers  170 ,  171 , and the packet  174  from the sorter unit  104 , and sends them to the switch  101 . 
         [0157]    If comprising multiple PE matrices, the above described apparatus  200  with dynamic reconfigurable processor for reconfiguring the packet based on the communication state, is capable of suppressing cache misses and reducing the time required for loading the configuration data by utilizing the scheduling unit to assign packets to the PE matrices. Further, this apparatus with dynamic reconfigurable processor is capable of reducing the loading time required due to caches misses, by pre-reading and transferring the configuration data required for processing the second packet during processing of the first packet. 
         [0158]      FIG. 12  is a flow chart showing transitions in the communication states (F-STATE 911 , B-STATE 921 ) accumulated by the communication state table  132 . 
         [0159]    The F-STATE 911  changes according to the packet data, and the F-STATE 911  within the communication state table. In the initial (first) stage, the F-STATE 911  is ‘0x000’ signifying the TCP connection is “CLOSED” (communication stop) ( 1201 ). After receiving the SYN packet (rcv SYN in  FIG. 12 ), the F-STATE 911  changes to ‘0x0001’ to signify “SYN RCVD” (start connection) ( 1202 ). Further, after receiving the ACK packet, (rcv ACK in  FIG. 12 ), the F-STATE 911  changes to ‘0x0003’ to signify “ESTAB” (communication established) ( 1203 ). 
         [0160]    After the F-STATE 911  has changed to ‘0x0003’, it changes according to the arriving packet payload. 
         [0161]    When the packet payload contains a GET command within the HTTP protocol, the F-STATE 911  changes to ‘0x0007’ to signify “HTTP GET” for requesting the return of the file requested by the client ( 1204 ). 
         [0162]    When the packet payload contains a POST command including the variable “/insert” within the HTTP protocol, the F-STATE 911  changes to ‘ 0 x000F’ to signify “HTTP POST INSERT” for requesting registry into the database for the item data sent by the client ( 1205 ). 
         [0163]    When the packet payload contains a POST command including the variable “/select” within the HTTP protocol, the F-STATE 911  changes to ‘0x0011F’ to signify “HTTP POST SELECT” for requesting selection of item data from the database ( 1206 ). 
         [0164]    When the packet payload contains a POST command including the variable “/check” within the HTTP protocol, then the F-STATE 911  changes to ‘0x003F’ to signify “HTTP POST CHECK” for requesting confirmation of data registry status in the database ( 1207 ). 
         [0165]    When the packet payload contains a POST command including the variable “/update” within the HTTP protocol, then the F-STATE 911  changes to ‘0x007F’ to signify “HTTP POST UPDATE” to request update of items in the database. ( 1208 ). 
         [0166]    When the packet payload contains a POST command including the variable “/delete” within the HTTP protocol, then the F-STATE 911  changes to ‘0x00FF’ to signify “HTTP POST DELETE” to request deleting of item data in the database ( 1209 ). 
         [0167]    When the packet payload contains a GET command including the variable “/UPLOAD” within the HTTP protocol, then the F-STATE 911  changes to ‘0x0107’ to signify “HTTP GET UPLOAD” for requesting upload of data in the item database to the server ( 1210 ). 
         [0168]    When all processing that was requested by the HTTP protocol commands has ended, after the F-STATE 911  changed to ‘0x0007’, 0x000F’, ‘0x001F’, 0x003F’, 0x007F’, ‘0x00FF’, ‘0x0107’, then the F-STATE 911  returns to 0x0003’ ( 1203 ). Further, when the packet containing a redundant ACK arrives, “0x0400” is added to the F-STATE 911 , and a “DUP” is attached for requesting fast recovery and fast retransmit by TCP congestion control ( 1211 ). When the FIN-ACK/RST-ACK packet arrives, the F-STATE 911  automatically returns to ‘0x0000’ regardless of the values in these packets. 
         [0169]    The B-STATE 921  changes when downloading server data to the cache, or when uploading the database contents accumulated in the cache, to the server. 
         [0170]    At the initial state, the B-STATE 911  is ‘0x0000’ signifying a “CLOSED” (communication stop) TCP connection state ( 1212 ). 
         [0171]    When the F-STATE 911  is ‘0x0007’, and the file requested by the client has not yet accumulated in the appliance memory, then the B-STATE 921  changes to ‘0x0001’ signifying “SYN SENT” (starting connection) ( 1213 ). The B-STATE 921  also changes to ‘0x001’ signifying “SYN SENT” (starting connection) even when the F-STATE 911  is ‘0x0107’ ( 1213 ). 
         [0172]    Further, when the SYN-ACK packet arrives from the server  504 , after the apparatus  200  sent the SYN packet to the back end server  504 , and the F-STATE 911  is 0x0007, then the B-STATE 921  changes to ‘0x000B’ signifying “DOWNLOAD” for requesting download of a file from the server  504  to the apparatus  200  ( 1214 ). When the F-STATE 911  is ‘0x0107’, then the B-STATE 921  changes to ‘0x010B’ signifying “UPLOAD” for requesting upload of the database cached in the memory within the appliance, to the server ( 1215 ). 
         [0173]    When the FIN-ACK/RST-ACK packet arrives, the B-STATE 921  automatically returns to 0 regardless of the values in these packets. 
         [0174]      FIG. 13  is a drawing of the configuration data cycle showing the state when the configuration data used according to the communication state, changes in each packet. 
         [0175]    The “Interrupt and Output Config.” ( 1301 ) is constantly executed during input of communication states from the packet I/O to the DRP. This configuration is executed on all packets, and executes processing to generate interrupts, and processing to calculate TCP/IP checksums and send the packet. This configuration is the most highly utilized and so should preferably be kept cached in the configuration data cache. 
         [0176]    The “TCP Control Config.” ( 1302 ) is especially for TCP connection control, and is utilized when the communication state for F-STATE 911  is ‘0x000’, ‘0x001’, ‘0x0003’, ‘0x04 . . . ’. Besides discarding packets containing abnormal TCP segment sequence/check numbers, this configuration also generates SYN-ACK packets when the communication status is “SYN RCVD”, and generates RST/FIN-ACK and ACK packets when the communication state is “CLOSED”. Further, this configuration is the most highly utilized so should preferably be kept cached in the configuration data cache. 
         [0177]    The “HTTP GET Control Config.” ( 1303 ) is utilized when the F-STATE 911  communication state is ‘0x0007’. First a decision is made whether the file requested by the client is accumulated in the cache. If the requested file is in the cache, then a packet including data for the requested file accumulated in the cache is generated for the client. However if the requested file is not in the cache, then besides generating a SYN packet for making a connection with the back end server, the B-STATE 921  is set to ‘0x000B’. 
         [0178]    The “DOWNLOAD Control Config.” ( 1304 ) is utilized when the F-STATE 911  communication state is 0x000B’. This configuration is for downloading a file from the server to the appliance. 
         [0179]    The “HTTP POST/select Control Config.” ( 1305 ) is utilized when the F-STATE 911  communication state is 0x001F’. This configuration selects item data from the DB (database) within the appliance memory according to the contents specified by the packet select command, and generates packets made up of item data translated into HTML/XML text format. 
         [0180]    The “HTTP POST/check Control Config.” ( 1306 ) is utilized when the F-STATE 911  communication state is 0x003F’ This configuration decides whether or not the item data specified by the client is registered in the DB, and generates a packet for notifying the decision results. 
         [0181]    The “HTTP POST/delete Control Config.” ( 1307 ) is utilized when the F-STATE 911  communication state is ‘0x00FF’ This configuration deletes the item data specified by the client from the DB, and generates a packet for notifying the decision results. 
         [0182]    The “HTTP GET/UPLOAD Control Config.” ( 1308 ) is utilized when the F-STATE 911  communication state is ‘0x0107’ This configuration sets the B-STATE 921  to ‘0x000B’, and generates an SYN packet for the back end server and, a packet for notifying the client that upload has started. 
         [0183]    The “UPLOAD Control Config.” ( 1309 ) is utilized when the F-STATE 911  communication state is ‘ 0 x010B’. This configuration uploads the contents of the DB accumulated in the appliance memory, to the server. 
         [0184]    The “HTTP POST/insert Control Config. 1” ( 1310 ) is utilized when the F-STATE 911  communication state is ‘0x000F’. This configuration decides whether the data inserted from the client is already registered in the DB or not. If the decision results show that the data inserted by the client is not registered in the DB, the DRP utilizes the “HTTP POST/insert Control Config. 2” ( 1311 ). This configuration inserts item data sent from the client into the DB within the appliance memory, and generates a packet informing the client that the data was inserted correctly. However, if the data from the client was registered in the DB, then the DRP utilizes the “HTTP POST/insert Control Config. 3” ( 1312 ). This configuration generates a packet for outputting an error message. 
         [0185]    The “HTTP POST/update Control Config. 1” ( 1313 ) is utilized when the F-STATE 911  communication state is ‘0x007F’. This configuration deletes the item data specified by the client as the object for updating, from the DB. The operation then switches to the “HTTP POST/update Control Config. 2” ( 1314 ) for reconfiguring. This configuration registers the item data updated by the client, into the DB. 
         [0186]    When the different processing for each communication state ends, the PE matrix is reconfigured to the initial configuration “Interrupt and Output Config.” by autonomous reconfiguring. 
         [0187]      FIG. 15 ,  FIG. 16 ,  FIG. 17  and  FIG. 18  are drawings showing the server service sequence achieved by the apparatus  200 . 
         [0188]      FIG. 15  shows the TCP connection control implemented by “TCP Control Config.” ( 1302 ). When a connection request packet arrives ( 1501 ) from the front end  501  terminal, for the server  504  serving as the back end terminal, the apparatus  200  attaches a random value y to the SEQ No. ( 1502 ), and returns the SYN-ACK packet ( 1503 ). If the transmit source for the connection request packet is an attacker  1500  utilizing a transmit source with a false name, then that attacker  1500  cannot receive the SYN-ACK packet and so does not know the Y value ( 1504 ). The ACK packet ( 1505 ) from the attacker  1500  does not contain the correct value Y+1, and so is judged abnormal and discarded ( 1506 ). The continuous transmit SYN packet ( 1507 ) from the same transmit source is also discarded ( 1508 ). The apparatus  200  judges that communication is normal at the point in time that the ACK number Y+1 serving as the ACK packet ( 1509 ) is received, and establishes the TCP communication. 
         [0189]      FIG. 16  is a sequence diagram showing the download of a file from the server  504  to the apparatus  200  using the “DOWNLOAD Control Config.” ( 1304 ) and, the download of a file from the apparatus  200  to the front end terminal  501  using the “HTTP GET Control Config.” ( 1303 ). 
         [0190]    First, the access terminal  501  and the apparatus  200  exchange an SYN packet  1601  an SYN-ACK packet  1602 , and an ACK packet  1603  by way of a TCP 3-Way-Handshake, and establish TCP communication. The access terminal  501  then utilizes the HTTP GET command to send a packet  1604  requesting the file A. 
         [0191]    The apparatus  200  contains a file table  1607  for caching files from the server, and a file pointer table  1606  for recording address pointers in each file. 
         [0192]    When the packet  1604  for requesting file A arrives, a search is made of the file pointer table  1606 , and a decision is made on whether the file A requested by the GET command is present in the cache or not ( 1605 ). 
         [0193]    If the file A is not cached in the file table  1607 , then a TCP 3-Way-Handshake establishes a connection with the server  504  by utilizing the SYN packet  1608 , and the SYN-ACK packet  1609  and the ACK packet  1610 . Also, a packet  1611  requesting the file A is sent, and the file A held by the server  504  ( 1618 ) is downloaded in accordance with TCP control ( 1611  through  1617 ), and recorded in the file table  1607 . The name of file A, and the address pointer where the file A is cached are recorded in the file pointer table  1606  and, the file accumulation ends ( 1620 ). 
         [0194]    When the file A is cached in the file table  1607 , this cached file A in the file table ( 1622 ) is returned under TCP control to the front end terminal  501  ( 1624  through  1630 ). 
         [0195]      FIG. 17  shows the registry of item data into the apparatus  200  from the front end terminal  504  by the “HTTP POST/insert Control Config. 1-3” ( 1310  through  1312 ; and the selecting of item data within the apparatus  200  by the “HTTP POST/select Control Config.” ( 1305 ); and the updating of item data within the apparatus  200  by the “HTTP POST/update Control Config. 1,2” ( 1313 ,  1314 ); and the deletion of item data within the apparatus  200  by the “HTTP POST/deleteControl Config. 1,2” ( 1307 ). 
         [0196]    The apparatus  200  contains a database table  1713  for caching database entries for the server; and a pointer table  1712  for recording multiple pointers according to items including the entries. 
         [0197]    When the packet  1701  with an attached POST command for requesting registry of an entry made up of three item data arrives at the apparatus  200  in HTTP protocol, the apparatus  200  then utilizes the pointer table  1712  to decide whether or not the entry requested for registry, is already registered in the database table. If not registered, then the apparatus  200  generates multiple pointers using the three item data, and registers them in the pointer table  1712 . The entry whose registry was requested is also registered in the database table  1713 . 
         [0198]    When the packet  1702  with an attached POST command for requesting deletion of an entry holding specified item data arrives at the apparatus  200  in HTTP protocol, the apparatus  200  deletes the pointer generated by the entry containing the item data of the entry whose deletion was requested, and the entry holding the item data for deletion from the database table  1713  and the pointer table  1712 . 
         [0199]    When the packet  1703  with an attached POST command for requesting updating of an entry holding specified item data arrives at apparatus  200  in HTTP protocol, the apparatus  200  deletes the pointer generated by the entry containing the item data of the entry whose updating was requested, and the entry holding the item data for updating, from the pointer table  1712  and the database table  1713 . The apparatus  200  further inserts a pointer generated by using three new item data, and an entry made up of three new item data, into the pointer table  1712  and the database table  1713 . 
         [0200]    When the packet  1704  with an attached POST command for requesting selecting of an entry holding specified item data arrives at the apparatus  200  in HTTP protocol, the apparatus  200  selects the entry holding the item data whose selection was requested from the pointer table  1712  and the database table  1713 . 
         [0201]    When the processes for registering, updating, selecting and deleting the data are completed, the processing results are returned under TCP control to the front end terminal ( 1705  through  1711 ). 
         [0202]      FIG. 18  is a diagram showing the upload of item data from the database table  1713  within the apparatus  200  to the server  504  by the “UPLOAD Control Config” ( 1309 ). 
         [0203]    The apparatus  200  receives a packet  1801  attached with a GET command for requesting the uploading of item data cached into the database table  1713  to the server  504 . The apparatus  200  then connects to the server  504  by way of a TCP 3-Way-Handshake utilizing the SYN packet  1812  and the SYN-ACK packet  1813  and the ACK packet  1814 . The apparatus  200  then sends a packet  1815  requesting upload of the item data, and uploads the item data under TCP control ( 1816  through  1823 ). The server  504  then updates the contents of the database utilizing that uploaded data. Under TCP control, the apparatus  200  also notifies the access terminal  504  of the upload results ( 1802  through  1808 ). 
         [0204]    By utilizing the dynamic reconfigurable processor apparatus to implement the processing described above using  FIG. 12  and  FIG. 13 , and  FIG. 15  through  FIG. 18 , varied server services can be achieved by reconfiguring each packet based on the communication states among the terminals.