Field of the invention

The present invention relates to an address server for managing network addresses and a method of attributing network addresses in a parallel computing environment.

Background of the invention

In a parallel computing environment, such as a High Performance Computing environment, there are large parallel applications running on thousands of nodes. It is necessary to run those applications into containers in order to be able to checkpoint and restart them. The technique known as Checkpointing involves saving the state of a running application into a file such that the complete state can be restored and the application continued at a future time. The technique known as Restarting involves restoring the state from a checkpoint file and resuming execution in such a way that the application continues to run as if it had not been interrupted (but possibly on a different set of compute nodes).

It is possible during the checkpoint and restart operations to save and restore the state of the TCP/IP connections, but this requires the virtualization of the network. To do so, at least one virtual IP address is associated to each container. The TCP/IP connections go through the virtual address, so they can be moved from a node to another. For a given application, all the virtual IP addresses must be belong to the same sub network. A virtual IP addresses must not be used at the same time by two different applications, or this will result in a TCP/IP conflict. Summary of the invention

According to the present invention there is provided a method of attributing network addresses to virtual machines as defined in the appended independent claim 1 ,

an apparatus according to the appended claim 7, a computer program according to the appended claim 8 and a computer readable medium according to the appended claim 9. Preferred embodiments are defined in the dependent claims.

Brief description of the drawings

Embodiments of the present invention will now be described by way of example with reference to the accompanying drawings in which like references denote similar elements, and in which: Figure 1 is a schematic representation of a server not belonging to the present invention;

Figure 2 shows is a schematic representation corresponding to that of figure 1 showing an

embodiment of the present invention;

Figure 3 is a flow chart showing the steps of an embodiment;

Figure 4a shows schematically the allocation of memory in accordance with an embodiment; Figure 4b shows schematically an alternative memory allocation situation in accordance with an embodiment;

Figure 5 shows the principle of splitting two contiguous non-homogeneous ranges to reserve a range spanning those two ranges;

Figure 6 is a flowchart of the steps of the beautification algorithm;

Figures 7a, 7b, 7c and 7d and 7e show an example of operations carried out according to the algorithm of figure 6; and in particular

Figure 7a shows a first stage in the beautification process;

Figure 7b shows a second stage in the beautification process;

Figure 7c shows a third stage in the beautification process;

Figure 7d shows a fourth stage in the beautification process;

Figure 7e shows a fifth stage in the beautification process; and

Figure 8 shows the effect of the compacting algorithm. Detailed description of the preferred embodiment

One may envisage a server adapted to manage a set of virtual IP addresses that can be used to run the parallel applications. In this context, the expression may primarily indicate a software entity which may be virtualised, or otherwise abstracted from the physical means supporting its functions. This server would allow clients to allocate a given number of free virtual IP addresses and to allocate or release a given set of virtual IP addresses. A useful feature of the server would be its ability to constantly save its state into a file on the disk to be able to restart in the same state in case of failure.

As parallel applications run on thousands of nodes, the would server need to manage several thousands of virtual IP addresses.

Figure 1 is a schematic representation of such a server not belonging to the present invention. As shown, the server 100 provides for each address, a representation of its value 111 and its state 112 in memory 110. This same information could be written into the statefile 130. In the messages exchanged between the server and the clients 121, all the addresses would be written one by one, so for example when a client sends a request to allocate a given number of addresses, the message would specify all required addresses. The server would then check all the addresses one by one by locating the memory section for that address 111, and reading the value of the associated status space 112, then update the state of each required address one by one

correspondingly. Each time the state of an address is updated, the server 100 will also update the statefile 130.

Although satisfactory for relatively small numbers of addresses, the inventors have determined that when the number of addresses is very large, the server would need a very large amount of memory, the statefile would be very large, the messages exchanged between the server and the clients are very large and the time required to process a request could potentially be undesirably long.

A range of addresses is described by its first and its last addresses. With only two addresses, it is possible to represent a range of hundred or thousands of addresses. This allows to save a lot of memory. All the addresses of a range share the same state. When the state of only some addresses of a range have to be changed, the range is first split into several ranges, then the state of the different ranges is set : a range for the addresses into the new state, and eventually ranges before and after the new range for the remaining addresses with the previous state. Whenever it is possible, ranges with the same state are merged. A sequence of addresses is considered to be homogeneous if every address in that sequence has the same status, as described hereafter. A range in accordance with the present invention is necessarily homogeneous.

Figure 2 shows is a schematic representation corresponding to that of figure 1 showing an embodiment of the present invention. As shown, the server 100 describes ranges of addresses in memory 110 by means of a start address 211, and end address 212 and a status field 214. This same information could be written into the statefile 130. This representation by range reduces drastically the memory footprint of the server, the size of the state file, the size of the messages exchanged between the server and the clients, and it improves the time taken by the server to process a request.

In an example with 640K (655340) addresses, the memory used by the server described with respect to figure 1 might be in the order of 30MB, whilst in accordance with the present embodiment it might be more in the order of 40Ko, that is a factor of 700 times fewer. Similarly the statefile used by the server described with respect to figure 1 might be in the order of 40MB, whilst in accordance with the present embodiment it might be more in the order of 4KB. A message exchanged between a client and the server described with respect to figure 1 might be were around 4MB whilst in accordance with the present embodiment it might be more in the order of 200B. The time required by the previous implementation to process a request was function of the number of addresses, it is now function of the number of ranges.

In the worst case, no two contiguous addresses have the same state, and the server needs to represent each address by a range. This is unlikely to happen, as the server will always allocate addresses as contiguously as possible. Such a situation can happen only if the user allocates explicitly only odd addresses for example.

Preferably successive requests for the same given number of addresses are cyclically attributed different ranges of addresses, even in a case where ranges that had previously be attributed have be released before the next request.

Accordingly, there is proposed an improved server wherein rather than representing each address in memory, ranges of addresses are used. Specifically, there is proposed a method of attributing network addresses to virtual machines wherein all available addresses are described as one or more continuous ranges, each range being respectively defined by a start address and an end address. The method comprises the steps of receiving a request for a given number of addresses from a requesting entity, comparing the length of continuous ranges of available addresses with the number of addresses requested, selecting a range of available addresses comprising a number of addresses greater than the requested number of addresses, defining a first new range comprising the requested number of addresses excised from said selected range,

defining one or more further new ranges comprising the remainder of said selected range not belonging to said first new range, and attributing the first new range for the use of the requesting entity, the further new ranges retaining their present status.

A continuous range is a range which includes every address which numerically or logically falls within that range. Thus the continuous range having a start value of 192.168.0.1 and the end value 192.168.0.5 necessarily includes the addresses 192.168.0.2, 192.168.0.3 and 192.168.0.4. It may be that certain addresses are unavailable, for example having been set aside for special purposes, in which case a continuous range may be considered to be continuous although skipping such reserved addresses. Two addresses are adjacent if one is the immediate numerical successor or predecessor of the other. Thus 192.168.0.2 and 192.168.0.3 are adjacent. Two ranges are adjacent if the start value of one range is adjacent the end value of the other. Adjacent ranges may also be referred to as contiguous, on the basis that they together describe an unbroken sequence of addresses, and yet are defined in terms of two separate ranges.

Figure 3 is a flow chart showing the steps of an embodiment. As shown, the method starts as step 305, before proceeding to step 310 at which a request for a given number of addresses is received from a requesting entity. The method proceeds to step 315 at which it compares the length of continuous ranges of available addresses with the number of addresses requested e.g. as defined in the address reservation memory 110. The method then proceeds to step 320 at which a range of available addresses comprising a number of addresses greater than the requested number of addresses is selected. The method then proceeds to step 325 at which a first new range comprising the requested number of addresses excised from said selected range is defined.

Similarly at the following step 330 the method defines one or more further new ranges comprising the remainder of said selected range not belonging to said first new range. The method then proceeds to attribute the first new range for the use of the requesting entity, the further new ranges retaining their present status, before terminating at step 335. According to one preferred embodiment, the step 315 of comparing the length of continuous ranges of available addresses with the number of addresses requested, involves comparing the length of all continuous ranges of available addresses with the number of addresses requested, and wherein said step of selecting involves selecting the most convenient available range of sufficient length.

According to another preferred embodiment, the step 315 of comparing the length of continuous ranges of available addresses with the number of addresses requested involves comparing the length of each continuous ranges of available addresses in turn until an available range of sufficient length is identified, and selecting said available range of sufficient length without comparing the length of further continuous ranges of available addresses with the number of addresses requested.

Description of the server API

According to an embodiment, the improved server recognizes the following requests :

- 'get'. This request gives the number of addresses to allocate, and returns the list of the ranges of the allocated addresses. According to one embodiment the server returns the first range of addresses it finds. According to the present embodiment all the ranges considered belong to the same sub network. Preferably, at each request, the server looks at a different sub network, so that the addresses so not always come from the same sub network. Preferably, the server cycles through the available sub networks.

- 'use'. This request gives the ranges of addresses to allocate, and just returns the status of the operation. The server checks that all the addresses are free then, if they are, allocates them.

- 'release'. This request gives the ranges of addresses to release (unallocate), and just returns the status of the operation. The server releases all the addresses in use. Note that according to certain embodiments some addresses may have been reserved, so they do not become free but reserved.

- 'make reservation'. This request gives the ranges of addresses to reserve, and returns the identifier of the reservation. The server creates the reservation and adds the reservation to all the addresses.

- 'check reservation'. This request gives the identifier of the reservation, and returns the state of the reservation (ready or not). The server retrieves the reservation and checks its state. - 'use reservation'. This request gives the identifier of the reservation, and returns the status of the operation. The server checks that the reservation is ready, and if it is, it deletes the reservation and allocates all the addresses part of the reservation.

- 'cancel reservation'. This gives the identifier of the reservation, and returns the status of the operation. The server deletes the reservation and removes it from all the addresses that were part of the reservation.

Description of the internal representation

There are several objects that are represented into the memory of the server : range of addresses, sub networks and reservations.

A range of addresses is an object that represents a set of continuous, sequential addresses with the same state and the same list of reservations. The properties of a range of addresses are the first address, the last address, the state of the range ('free', 'in use' or 'reserved'), the number of addresses in the range and the list of reservations associated to the range. Two ranges can be merged if they are contiguous, are in the same state and share the same list of reservations.

A sub network is an object that groups all the range of addresses that contain addresses from this sub network. The properties of a sub network are the address of the sub network, its mask and the list of ranges part of the sub network.

A reservation is an object that associates a set of reserved addresses with an identifier. The properties of a reservation are its identifier and the list of the ranges of addresses part of the reservation. A reservation listens for the changes of the ranges of addresses that are part of the reservation. If a range is split, then the new range is added to the list of ranges part of the reservation. When two ranges are merged, the removed range is removed from the list of ranges that are part of the reservation. This allows the list of ranges that are part of the reservation to remain consistent. When the state of a range changes, the reservation updates its state. If all the ranges are now in the state 'reserved' and that the reservation is the first of the list, that means that the reservation is ready to be used.

The server references all the sub networks and all the reservations. Description of a 'get' request

A client makes a 'get' request to have a given number of addresses from the same sub network. The server first looks for a sub network with enough free addresses. Then it parses the free ranges of the sub network and asks the sub network to allocate the addresses of the ranges until it has the required number of addresses. The ranges are allocated entirely except the last range which may be allocated partially to have the exact count.

Figure 4a shows schematically the allocation of memory in accordance with an embodiment. In order to allocate a range of addresses 400, the sub network looks for a free range 405 where to allocate the addresses. If the range of addresses to allocate matches the free range 405, then the state of the free range is simply changed to 'in use'. If the range of addresses to allocate is at the beginning or at the end of the free range 405, then the free range 405 is split into two ranges 410 and 415, one range 410 in the state 'in use' that contains the addresses to allocate and the other 415 in the state 'free' with the remaining addresses.

Figure 4b shows schematically an alternative memory allocation situation in accordance with an embodiment. If the range of addresses 400 as described with respect to figure 4a to allocate is within the free range 405 as described with respect to figure 4a, then the free range 405 is split into three ranges 420, 425, 430: two ranges 420, 430 in the state 'free' and in the middle a range 425 in the state 'in use' that contains the allocated addresses.

Description of a 'use' request

A client makes a 'use' request to allocate a given set of addresses, given as a list of ranges of addresses.

The server first beautify the list of ranges. Then it retrieves to which sub network the addresses belong, and it retrieves to which ranges of the sub network the addresses belong. Once the server has all the ranges of addresses that contain the addresses to allocate, it checks that all the ranges are in the state 'free'. If they are, then the server ask the sub network to allocate all the addresses. The way a sub network allocates addresses is described in the previous section.

Description of a 'release' request

A client makes a 'release' request to release (unallocate) a given set of addresses, given as a list of ranges of addresses.

The server preferably first beautifies the list of ranges as described with reference to the beautifying algorithm hereafter. Then it retrieves to which sub network the addresses belong, and it asks the sub network to release all the addresses.

In order to release a range of addresses, the sub network first checks that all the given addresses exist in the ranges of addresses. Then it browses all the ranges and modifies the ranges that contain addresses that are to be released. If the state of the range is 'reserved' or 'free', it does nothing. If the state of the range is 'in use', the sub network changes the state to 'free' or to 'reserved' if there is a reservation on the range. If all the addresses of the range are not to be released, then the range is first split, then only the state of the new range corresponding to the addresses to be released is changed. After this, the sub network invokes the compact routine to eventually merge some ranges as described with reference to the compacting algorithm hereafter.

Description of a 'make reservation' request

A client makes a 'make reservation' request to reserve a given set of addresses, given as a list of ranges of addresses.

The server preferably first beautifies the list of ranges as described hereafter. Then it retrieves to which sub network the addresses belong. It defines a new reservation identifier, then it asks to the sub network to reserve all the addresses. Finally, it creates a new reservation with all the addresses.

In order to reserve a range of addresses, the sub network first checks that all the given addresses exist into the ranges of addresses. Then it parses all the ranges to add the reservation in their reservation queue. If the ranges does not match the ranges of addresses to be reserved, then the sub network first split the existing ranges before to add the reservation on the appropriate ones.

Once a range is defined as reserved, in the case where the requesting entity is not the reserving entity, during the attribution process the reserved range is disregarded at said step of comparing the length of that range of available addresses with the number of addresses requested.

Figure 5 shows the principle of splitting two contiguous non-homogeneous ranges to reserve a sequence of addresses spanning those two ranges. As shown, a reservation request is received for a particular range 505. The sequence of addresses 505 straddles two ranges 510, 520, defined in the address reservation memory. The first defined range 510 has the status "free", while the second defined memory 520 has the status "in use", that is, attributed to a particular client. In order to implement the "make reservation" instruction, the two ranges 510, 520 are each split so that there are now four ranges. The ranges at the extremities, 511 and 521 retain the status of the originally defined ranges 510, 520, whilst the two inner ranges 515, 525 accumulate respectively the status of the originally defined ranges from which they were split, and the status "reserved". Finally, it invokes the compact routine to potentially merge some ranges as described hereafter, and returns all the ranges that have been reserved.

Description of a 'check reservation' request

A client makes a 'check reservation' request to check whether a reservation is ready or not.

The server retrieves the reservation, then it returns its state.

Description of a 'use reservation' request

A client makes a 'use reservation' request to switch all the addresses part of the reservation in the 'in use' state. The reservation is then destroyed.

The server retrieves the reservation, then it asks the reservation to use the addresses. If this operation succeeds, it removes the reservation from the reservation list and destroy it.

In order to use a range of addresses, a reservation parses all the ranges part of the reservation, changes their status to 'in use' and remove the reservation from the queue of reservations of the range.

Description of a 'cancel reservation' request

A client makes a 'cancel reservation' request to cancel a reservation. The reservation is destroyed, all the addresses that were reserved by this reservation are freed (or they remain reserved, but the next reservation in their queue).

The server retrieves the reservation, then it asks the reservation to cancel itself. If this operation succeeds, it removes the reservation from the reservation list and destroy it.

In order to cancel itself, a reservation parses all the ranges part of the reservation. For each range, the reservation looks at their state. If the state of the range is 'reserved', then it changes the state to 'free' if there are other reservations, else it let the range in the state 'reserved', the range is simply now reserved by another reservation. If the state of the range is 'in use', it does not change the state of the range. In any case, the reservation removes itself from the reservation queue of the range.

Description of the beautifying algorithm

This algorithm constructs a new beautified list of ranges of addresses from a given list of ranges of addresses, e.g. in a case where a client requests attribution of a list of ranges . A beautified list of ranges is a list of ranges where all the ranges are not contiguous and sorted by ascendant order. So the algorithm has to remove any duplicates, merge any contiguous ranges or any ranges that intersect and sort the ranges by ascending order. The algorithm is the following :

- iterate through the given list of ranges. For each range, do :

- if the beautified list of ranges is empty, then insert the range into the beautified list and process next range.

- iterate through the beautified list of ranges. For each range, do :

- if the last address of the range is less than the first address of the range of the beautified list, then insert the range into the beautified list of ranges before the current range and stop iterating the beautified list.

- if the last address of the range is the one right before the first address of the range of the beautified list, then merge the ranges by changing the first address of the range of the beautified list to the first address of the range and stop iterating the beautified list.

- if the first address of the range is greater or equal to the first address of the range of the beautified list and less or equal to the last address of the range of the beautified list, then merge the intersected ranges by changing the last address of the range of the beautified list to the last address of the range and stop iterating the beautified list.

- if the iteration of the beautified list is complete but the range has not processed, then add at the end of the beautified list.

Figure 6 is a flowchart of the steps of the beautification algorithm. As shown, the method starts at step 605 before proceeding to the 610 at which the first range defined in the address reservation memory is selected by setting n to 1, where n is the number of the range presently selected. Since this is the first range to be processed, the beautified list is necessary empty at this stage, so the method immediately adds the first range to the beautified list at step 615. The method proceeds to step 640 at which n is incremented. The method next determines whether n now exceeds the number of ranges defined in the address reservation memory at step 645. If n now exceeds the number of ranges defined in the address reservation memory, the method terminates at step 650. Otherwise, the method proceeds to step 655 at which it is determined whether the last address of the nth range is less than the first address of the range of the beautified list. If the last address of the nth range is less than the first address of the range of the beautified list, the method proceeds to step 660 at which it is determined whether the last address of the nth range is the one right before the first address of the range of the beautified list. If it is determined that the last address of the nth range is the one right before the first address of the range of the beautified list the method proceeds to step 665 at which the presently selected range is inserted into the beautified list of ranges before the current range before returning to step 640. If it is determined that the last address of the nth range is not the one right before the first address of the range of the beautified list the method proceeds to step 670 at which the presently selected range is merged into the range defined in the beautified list by changing the first address of the range of the beautified list to the first address of the range. If at step 655 it is determined meanwhile that the last address of the nth range is not less than the first address of the range of the beautified list, the method proceeds to step 675 at which it is determined whether the first address of the nth range is greater or equal to the first address of the range of the beautified list. If it is determined that the first address of the nth range is greater or equal to the first address of the range of the beautified list, the method proceeds to step 620 at which the presently selected range is added to the beautified list before returning to step 640. Otherwise the method proceeds to step 680 at which it is determined whether the first address of the nth range less or equal to the last address of the range of the beautified list. If it is determined that the first address of the nth range less or equal to the last address of the range of the beautified list the method proceeds to step 685 at which the intersected are merged ranges by changing the last address of the range of the beautified list to the last address of the range before returning to step 640. Otherwise the method proceeds to step 620.

Figures figures 7a, 7b, 7c and 7d and 7e show an example of operations carried out according to the algorithm of figure 6.

Figure 7a shows a first stage in the beautification process. As shown the first range from the address reservation server to be processed is the range 710. As described with reference to figure 6, the first range is immediately added to the beautified list as range 750.

Figure 7b shows a second stage in the beautification process. The next range from the address reservation server to be processed is the range 720 which is situated in a higher range of addresses the range 710, albeit somewhat overlapping. Accordingly the response to step 655 is "no", and to step 675 and 680 are "no" and "yes" respectively, leading to step 685, whereby the new range 720 is merged into the range 750 to form a new beautified list range 751.

Figure 7c shows a third stage in the beautification process. The next range from the address reservation server to be processed is the range 730 which is situated in a higher range of addresses the range 751 without overlap. Accordingly the responses to step 655 is "no", and to step 675 is "yes", leading to step 665, whereby the new range 730 is added as a new beautified list range 752.

Figure 7d shows a fourth stage in the beautification process. The next range from the address reservation server to be processed is the range 740 which is situated in a range of addresses between the range 751 and 752, without overlap. The process takes the range 751 as the first basis of comparison, and accordingly the responses to step 655 is "no", and to step 675 is "yes", leading to step 665, whereby the new range 730 is added as a new beautified list range.

Proceeding to take range 752 as the first basis of comparison, the responses to step 655 is "yes", and to step 660 is "yes", leading to step 670, whereby the new range 740 is merged into the second 730 beautified list range 752 to form a new beautified list range 753.

Figure 7e shows a fifth stage in the beautification process. As described above the algorithm has built a new beautified list of ranges sorted by ascendant order, but there are still two ranges 751 and 753 that can still be merged, so another pass is executed.

- iterate through the beautified list of ranges. For each range from the second one to the end, do :

- if the current range is contiguous to the previous one, then merge them by changing the last address of the previous range to the last address of the current range. Then remove the current range. The beautified list is now ready, with a single contiguous range 754.

Description of the compacting algorithm

This algorithm compacts the ranges of a sub network.

It iterates through the ranges of the sub network, starting from the second one, and does the following operations :

if the last address of the previous range and the first address of the current range are contiguous and the ranges are in the same state and have the same reservation list, then merge the current into the previous range by changing the last address of the previous into the last address of the current range and removing the current range (see figure 4).

Figure 8 shows the effect of the compacting algorithm. As shown, two ranges having the same status (in this case "free") 810, 820 are merged to form a new range 830, having the same status as the original two. Description of the statefile mechanism

Preferably, when the address server starts, it reads from a file the set of addresses it has to manage. If the state file is activated, the server looks for a state file. If the state file exists, then it reads it to restore its state. If the state file does not exist, then it create the state file and writes its state into it. Then the server constantly updates the statefile each time a request is processed and some changes made to its internal state.

As the internal state of the server is made of a variable number of ranges, it is not possible to modify an existing statefile. One approach to maintaining the state file is to rewrite the statefile completely each time the internal state of the server is changed. More preferably, the server is adapted to write its state into the state file followed by a separator. Then each time a change is made into the internal state of the server, the server appends a description of the change. This is faster and more simple. When the server needs to restore its state from the statefile, it reads the initial state from the statefile (up to the separator), then reads all the changes recorded after the separator and re-implements them. In order to avoid that the state file becomes too large, the state file may be rewritten entirely every so often, for example every hundred changes.

According to a further embodiment there is provided a server for attributing network addresses to virtual machines in a parallel computing environment, whereby the server defines the available range of network addresses as one or more ranges defined in terms of a start address, an end address and one or more status values applying equally to every address in the range. Status values may be "in use" "available" "reserved" etc. When a virtual machine requests a set of ranges, the server selects an existing range comprising sufficient addresses to satisfy the request, and splits it into new ranges, one of which comprises exactly the number of requested address, this range being attributed to the requesting virtual machine. A beautification algorithm regularly parses the ranges to merge adjacent ranges having identical status.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk - read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.