WO2010035216A1

WO2010035216A1 - Method and apparatus for reducing port contention

Info

Publication number: WO2010035216A1
Application number: PCT/IB2009/054147
Authority: WO
Inventors: Santosh Patil; Petr Smrz; Subramanian Rs
Original assignee: Nokia Corporation
Priority date: 2008-09-25
Filing date: 2009-09-22
Publication date: 2010-04-01
Also published as: GB0817623D0

Abstract

The problem of contention by applications for access to transport layer end ports is addressed by two mechanisms. The first mechanism is that of providing a dedicated generic port listener for each port that acts to accept or decline incoming connections on a port. In such a case only one listener monitors the port, and contention between applications is reduced. The second mechanism is the provision of a thin protocol aware layer between the transport layer ports and the client applications. The protocol aware layer comprises one or more protocol registers which are each able to parse an incoming data connection to determine whether it is in accordance with an application layer protocol. A protocol register has knowledge of applications which make use of the protocol and is able to route the data connection to one of the applications registered therewith.

Description

Method And Apparatus For Reducing Port Contention

Technical Field

The present invention relates to a method and system for reducing contention for the use of ports by applications providing services in a data network.

Background to the Invention

Internet protocol networks (such as the Internet) represent their components as part of a five layer model, commonly referred to as the TCP/IP model. In Internet protocol terminology, the transport layer end point is referred to as a "port". The port is a 16 bit number local to a host, and forms part of a socket address, comprising the IP address of the host, and the port number. Connections between applications are defined by the socket identifiers at both ends.

Summary of the Invention

Various examples of the invention are set out in the claims.

According to a first aspect of the invention there is provided a method, comprising: receiving data connections addressed to a port at a port listener associated with the port; maintaining, for an application layer protocol, at least one protocol register having a list of applications providing services which use the application layer protocol; and routing received connections from the port listener to said applications via said at least one protocol register; wherein contention for access to transport layer end ports in a host device is reduced.

According to another aspect of the invention there is a provided a host device for one or more applications providing services, the host device comprising: an application layer having one or more applications providing services to users; and a transport layer having a plurality of end ports through which data streams to and/or from said applications pass; said device further comprising: one or more port listeners, each associated with a particular port of the transport layer; and a protocol aware layer comprising one or more protocol registers, each protocol register being associated with an application- layer protocol and having a list of those of said applications providing services which make use of said application-layer protocol, the arrangement being such that a data connection received at one of said ports is routed to an application in the application layer via one of said protocol registers.

According to another aspect of the invention there is also provided an apparatus, comprising: at least one processor; and at least one memory including computer program code the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform at least the following: receive data connections addressed to a port at a port listener associated with the port; maintain, for an application layer protocol, at least one protocol register having a list of applications providing services which use the application layer protocol; and route received connections from the port listener to said applications via said at least one protocol register; wherein contention for access to transport layer end ports in a host device is reduced.

Description of the Drawings For a more complete understanding of example embodiments of the present invention, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

Figure 1 is a block diagram of two Internet hosts;

Figure 2 is a block diagram of an Internet host according to an example embodiment of the present invention;

Figure 3 is a flow diagram of the operation of the Internet host according to the example embodiment of the invention;

Figure 4 is a flow diagram of the further operation of the Internet host according to the example embodiment of the invention; and

Figure 5 is a block diagram of an apparatus according to another example embodiment of the invention.

Detailed Description of Example Embodiments

Figure 1 illustrates two hosts 10 and 20, each being a machine such as a computer, smart phone, camera, media player, etc., etc., which is able to run one or more application programs, such as application app_l, app_2, app_3, •••, app_n, as shown. Hosts 10 and 20 provide for the application layer programs to communicate with each other via the Internet 2, being a collection of Internet protocol networks so as to establish connections between the respective applications on each host 10, 20. For example, app_l on host 10 in one example is a web server application, such as Microsoft Information Interchange Server, or Apache Server. In such an example, app_l on host 20 is a web browser, such as Microsoft Internet Explorer, Mozilla Firefox, or the like. To allow a user of the web browser on host 20 to access the content provided by the server on host 10, connections are established between the web browser application and the server application, using the TCP/IP model. Here, although the model is referred to as the "TCP/IP" model, in other examples other transport layer protocols, such as UDP (User Datagram Protocol) may also be used. In the following, imagine a connection is being established between app_l of host 10, and app_l of host 20.

App_l of host 10 generates a data stream to be transmitted to app_l of host 20. This data stream will be data typically formatted in accordance with a particular application layer protocol. Common application layer protocols that are used include HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol), RTP (Real Time Transport Protocol), and the like. The precise protocol used will depend upon the nature of the application forming the connection. For example, for the web server application of the present example, it uses HTTP.

The application App_l generates a stream of data in accordance with the protocol being used, and passes this to the transport layer 106, via a transport layer end point, sometimes generically referred to as a Transport Service Access Point (TSAP). More specifically, however, in Internet protocol terminology, the transport layer end point is referred to as a "port". The port is a 16 bit number local to a host, and forms part of a socket address, comprising the IP address of the host, and the port number. Connections between applications are defined by the socket identifiers at both ends, and a socket (i.e. a particular port on a particular host) may be used for multiple connections at the same time.

Port numbers below 1024 are called "well known ports", and are reserved for standard services. For example, any process wishing to establish a connection to a host to transfer a file using FTP can connect to the destination host port 21 to contact the host's FTP daemon. The list of well known ports is maintained by IANA, and is given at www.iana.org. For example, the SMTP application layer protocol uses port 25, whereas the HTTP application layer protocol uses port 80. Hence, an application which wishes to send HTTP content via an Internet connection passes the data (formatted according to the application layer protocol) to the port in the transport layer which relates to that particular protocol e.g. via a web server, the HTTP stream is passed to port 80 in the transport layer. The transport layer 106 may itself use one of several protocols. The most commonly used transport layer protocols are TCP (Transport Control Protocol), and UDP (User Datagram Protocol). However, other transport layer protocols exist, and typically have particularly specific uses. For example, the Resource Reservation Protocol (RSVP) is designed to reserve resources across a network, and may be used in some examples to set up Internet connections. For present purposes, the purpose of the transport layer 106 and 206 in each host 10 and 20 is to accept the data streams via the transport layer end ports 104 from the applications, and to break the data streams up into datagrams, for transmission over the network.

The datagrams produced by the transport layer 106 are then passed to the IP network layer 108, wherein the transport layer datagram is encapsulated in an IP datagram, having network addressing and other information placed in an IP header. The IP datagram is then passed to the lower layers, being the data link layer, and the physical layer, which in Figure 1 are represented by a network interface 110. The operation of the data link layer, and the physical layer is beyond the scope of the present specification, suffice to say that the network layer, data link layer and the physical layer act together to actually transmit the data of the IP datagram over an external network, or collection of networks.

At the receiving host the identical operations are performed in reverse. That is, the network interface 210, comprising the physical layer, and data link layer, provides to the IP layer 208 an IP datagram, out of which the transport layer datagram can then be obtained, and passed to the transport layer 206. Depending on the transport layer protocol used, a data stream may be reconstructed in the order in which it was transmitted (for example using TCP), or may instead by output directly to the application layer. In either event, a data stream is output from the appropriate port to which the data was addressed, and can then be accessed from that port via the application layer application. Whether the data stream is in the same order as the transmitted data stream will depend on the transport layer protocol used.

One of the problems with the above described operation is that of port blocking. More particularly, because each application layer protocol commonly uses a particular transport layer port (for example port 80 for HTTP) and then if there are more than one applications providing different services which need to listen on that same port, then they contend for connections through that port. For example, web services, such as, for example, provided by server applications such as IIS Server, or Apache Server, use HTTP, and hence listen on port 80 for incoming connections. However, other services, such as universal plug and play (UPnP) also use HTTP as the application layer protocol, and hence also listen on port 80. Although multiple connections can be used on the same socket (port and IP address combination) where different applications on the same host are trying to access the same port then contention can occur, causing problems. Because of this it is often not possible to run multiple services which use the same port. For example, it is not possible to run the Microsoft Information Interchange server, and Apache server at the same time when one of them has acquired the port. This situation is shown in Figure 1, wherein app_2 on host 10 tries to access port_x, but is unable to do so, as app_l already has a connection through port_x.

In a first example embodiment of the invention contention by applications for access to transport layer end ports is addressed through the provision of two mechanisms, as will be described with reference to Figure 5.

Figure 5 is a block diagram illustrating a host device 1 having a processor 2 and an input/output port 3 through which logical data connections can be made. The device is further provided with a memory 4 storing computer program code in the form of application programs 5, protocol registers 6, and port listeners 7. The application programs 5 together form an application layer, the protocol registers 6 together from a protocol- aware layer, and the input/output interface 3 is part of a transport layer over which data is transported to other host devices. The operation and interaction of the application programs 5, protocol registers 6, and port listeners 7 to provide the two mechanisms noted above is described next.

The first mechanism is that port contention is resolved by providing a dedicated generic port listener for each port_s and which accepts new connections for that port. In this example one such listener 7 is provided for each port, listening for data arriving at the port, and the listener 7 acts to accept or decline incoming connections on a port. However, each listener 7 is independent of the applications 5 providing services which use the protocol associated with the port. By having a generic listener 7 for each port, instead of an application specific listener, then only one listener monitors the port, and contention between applications 5 is reduced or even prevented entirely.

The second mechanism used in the example embodiment is the provision of a thin layer between the transport layer ports and the client applications 5, which is a protocol aware layer which is aware of the application- layer protocols in use by the client applications. The protocol aware layer comprises one or more protocol registers 6 which are each able to parse, at least to some degree, an incoming data connection to determine whether the data therein is in accordance with the application layer protocol associated with a particular protocol register 6. Additionally, applications (5) which make use of the application layer protocol with which a protocol register 6 is associated register therewith when they start. Hence, any particular protocol register 6 is able to determine whether an incoming connection has data in accordance with the application-layer protocol to which the register relates, and if so, is further able to route the data in the data connection to one of the applications 5 registered therewith which is able to make use of the data. The port listener 7 and the thin protocol- aware layer comprising registers 6 may, in one example, be viewed as an application defined protocol interface which receives packets from lower layers and demultiplexes them up to place each packet on the proper channel.

In other words, the second mechanism is that the generic listeners 7 communicate with a protocol aware layer, which contains specific protocol register entities 6 for each different type of application layer protocol. In one example more than one register entity 6 is provided for each protocol, for example if a particular application layer protocol is used by different types of service. The applications themselves which use the application layer protocols register with the particular protocol register relating to the protocol used by the application when the application starts, such that the protocol register for a particular protocol knows that there is an application 5 running which makes use of the protocol to which it relates. Each protocol register 6 is able to parse the first few packets of data which it receives from the port listener 7, to determine whether the received connection uses the protocol relating to the particular protocol register. If a received data stream is in accordance with the protocol to which the protocol register 6 relates, then the protocol passes the data stream from the connection on to one or more of the applications 5 which are registered therewith. By using the above two mechanisms, i.e. the generic listener for each port in combination with the protocol registers in the protocol aware layer, in the present example different services which use the same application layer protocol can still access the same port, and contention between the services for use of the port is prevented.

A second example embodiment of the invention will now be described with reference to Figures 2 to 4.

Figure 2 illustrates a host 12 according to the second example embodiment of the invention. The second example embodiment provides for generic port listeners to be provided, which communicate with protocol registers in a protocol aware layer. The protocol registers communicate with application processes, providing services to users. Figure 2 illustrates those parts of the host 12 which relate to the second example, and it should be understood that those parts of the host which are not shown in detail are otherwise conventional. That is, the second example embodiment of the invention is not concerned with the operation of the transport layer, IP layer, data link layer, or physical layer. Instead, the second example embodiment of the invention is concerned with the transport layer end ports, and how these are accessed by applications providing services to users.

As with the first example discussed previously, the second example embodiment of the invention provides two main mechanisms to solve the problems noted above. The first mechanism is that the second embodiment provides, for each transport layer end port, a generic port listener, to listen for connections coming into the port. The listeners are contained within a listener container 40. For example, for port 80, which relates to HTTP, the port 80 listener 42 is provided. For port 25, which is used by the SMTP protocol, the port 25 listener 44 is provided. More generally, for port n, the port n listener 46 is provided.

Each port listener 42, 44, 46 is substantially identical, and acts to listen for new connections passed to a port from the transport layer. When a new connection is received at the port for which a listener is running, the listener accepts the connection, and then passes it in turn to the protocol registers associated with the listener, in a manner to be described. If a protocol register accepts the connection, then the port listener continues to pass through data belonging to the connection in a data stream. Alternatively, if no protocol register accepts the connection, then the listener declines the connection.

The second mechanism used by the second embodiment is, as noted above, a protocol aware layer, which contains multiple protocol register entities. More particularly, the protocol aware layer 30 in the present embodiment comprises, for this example, an HTTP (web) register 32, a HTTP (UPnP) register 34, and an SMTP register 36. The HTTP (web) register 32 acts as a thin interface between web service applications 51 and 52, and the port 80 listener 42. As will be described in more detail, the HTTP (web) register 32 maintains a record of which web services are running at the present time, and acts to parse data from a connection passed to it from the port 80 listener, to determine whether the connection should be accepted by any of the web service applications registered therewith.

The HTTP (UPnP) register provides a similar service for UPnP applications 53 and 54. The SMTP register 36 communicates with port 25 listener 44 (for the SMTP port), and provides a register for SMTP applications, such as SMTP service 55. SMTP service 55 may, commonly, be an email program, or the like.

More generally, the protocol aware layer 30 will contain a register for each application layer protocol which is made use of by any application layer service. The protocol register will communicate with the appropriate generic port listener contained in the listener container 40 for the application layer protocol in question. There may be more than one protocol register for each application layer protocol, and in particular where the same application layer protocol is used by different types of service. For example, HTTP is used by applications providing web services, but is also used as the application layer protocol for the transport of UPnP commands and data. In such a case, where the same application layer protocol is used by different types of service, a protocol register is provided for each type of application service which uses the protocol.

The operation of the generic listeners 42 to 46 contained within the listener container 40, and protocol registers 32 to 36 in the protocol aware layer 30 will now be described with respect to Figures 3 and 4. More particularly, Figure 3 illustrates the actions performed when an application providing a service to a user launches, and how the registers in the protocol aware layer then react. Figure 4 illustrates actions involved in the operation of the generic listeners and the protocol registers in routing incoming connections to the appropriate application service.

More particularly, consider the host 12 with no applications that provide services running. In this case, the listener container 40 will be empty, as there will be no need for port listeners to be operating. However, in the present second example embodiment the protocol aware layer 30 will exist, with protocol register processes running for each application layer protocol for which there are applications installed on the device. In other example embodiments, it may be that there are also no protocol register processes running after device start up, and that these are started only when an application providing a service to a user starts.

At block 3.2, assume that an application launches. For example, any of the applications providing services 51 to 55 may launch, such as, for example, web service 51. When an application is launched then as part of the launch process the application registers with the one or more protocol registers for the protocols used by the application, at block 3.4. For example, therefore, where a web server application launches, then the application registers with the HTTP (web) register 32. Where a universal plug and play service is launched, then that service registers with the HTTP (UPnP) register 34. Similarly, by way of example, where an email service launches which makes use of SMTP, then that SMTP service registers with the SMTP register 36.

When a protocol register first registers an application, if the protocol register has no other applications presently registered therewith then it will be necessary for the protocol register to request for a port listener to be launched, at block 3.6. This is then achieved at block 3.8, wherein a port listener is launched by the listener container 40, and acts to listen to the port for the protocol associated with the protocol register. Of course, if there are already applications running that are registered with a particular protocol register, then the protocol register will have already caused the port listener for that protocol to be running, and no additional listener will be launched. In this way, only one port listener is run at any one time for each port, and contention between applications for access to the port is removed. Instead, each interested application will obtain access to the port in a controlled manner via the protocol register, as will be described.

The operation of the port listeners, protocol registers, and the interaction with the application services will be described later with respect to Figure 4. Staying with Figure 3 for the time being, blocks 3.10 to 3.16 illustrate what happens when an application providing a service to a user closes.

More particularly, at block 3.10 imagine that an application providing a service to a user closes, e.g. web server program 52 providing web service 1 is closed down. As part of the shutdown process the web service de-registers with the protocol register with which it is registered, at block 3.12. Where the application is registered with multiple protocol registers, then the application de-registers with each of the protocol registers.

When an application de-registers with a protocol register, the protocol register then determines whether any other applications are still registered therewith. If no such applications are registered, then that means that there are no applications running which require the protocol with which the protocol register is associated. For example, in Figure 2, if neither web service 1 nor web service 2 are running, then the HTTP (web) register 32 will have no applications registered therewith. In such a case, the protocol register which has no applications registered therewith informs the listener container 40 that it no longer needs the port listener for the port associated with the protocol of the protocol register. Thus, for example, in the example of Figure 2, where the HTTP (web) register 32 has no applications registered therewith, then it would inform the listener container 40 that it has no need for the port 80 listener to be run.

However, the port 80 listener may be used by other protocol registers. If this is the case, then the port 80 listener should be maintained, and not shut down. However, if all protocol registers which make use of a port listener report that they have no registered applications for their respective protocols, then the listener container 40 can shut the port listener down, and this is performed at block 3.16. For example, if both the HTTP (web) register 32, and the HTTP (UPnP) register 34 have indicated to the listener container 40 that they have no applications registered therewith, then the listener container 40 may shut down the HTTP listener 42.

Similarly, if the SMTP register 36 reports to the listener container that it has no SMTP service applications registered therewith, then the listener container 40 can shut down the SMTP listener 44. Such operation makes sure that port listeners are not running unnecessarily. It also allows for applications which provide services which are not aware of the protocol aware layer to have an opportunity to start a listener outside of the context of the listener container 40, to listen for connections on the port. Whilst such applications that are not aware of the protocol aware layer 30 may cause contention for use of a port, by closing down the listeners in the listener container 40 when not required, there is a possibility for applications which are aware of the protocol aware layer to coexist on a host at the same time as applications, such as legacy applications, which do not make use of the protocol aware layer.

Figure 4 illustrates the operation of the port listeners and the protocol registers of the second example embodiment when a connection is received at the host 12. More particularly, at block 4.2 assume that an incoming connection is received at the transport layer of the host, and passed to the transport layer end port (socket) identified in the address. In this respect, it will be recalled that each TCP header has the source port and destination port address contained therein. The transport layer thus routes the incoming data stream to the end port indicated in the TCP header.

At block 4.4, assuming that there is an application running which provides a service which makes use of the protocol used by the port to which the incoming connection has been routed, then a port listener will be running, contained within the listener container

40. The connection is then received by the port listener for the particular port to which the connection has been routed, at block 4.4. The listener temporarily accepts the connection, and receives the first few data packets thereof. The connection is then passed up to the protocol registers in the protocol aware layer 30, as follows.

More particularly, in this example embodiment for there to be a port listener running at all, it must be the case that there is an application providing a service which makes use of the protocol, and that application will be registered with the protocol register associated with the protocol used by the application. It may be that in fact there are plural protocol registers serving applications which provide services which make use of the same application layer protocol. In such a case, the port listener for that protocol will be aware of the plural protocol registers in the protocol aware layer, and must give each protocol register the opportunity to receive the connection. To achieve this, therefore, at block 4.6 a processing loop is started to allow for each protocol register which uses the port, and of which the port listener for the port is aware. In particular, within the processing loop, the port listener passes the connection to the first protocol register in its registered list at block 4.8. The first protocol register receives the connection, and parses the first few packets received by the port listener, to determine if the received packets contain data in accordance with the protocol to which the protocol register relates. For example, if the incoming connection relates to a request for a web page, then the incoming connection may include an HTTP GET request, which can be passed to a web server. At block 4.10, therefore, a protocol register which has received the first few packets of the incoming connection from the port listener parses those data packets to determine if it wishes to accept the connection.

If the register does wish to accept the connection i.e. the received packets are in accordance with the protocol associated with the protocol register, then the register accepts the connection at block 4.18. On the other hand, if the packets are not in accordance with the protocol associated with the protocol register, then the register declines the connection at block 4.12. In this case, the port listener 80 then accesses the next protocol register in its list, at block 4.14, and blocks 4.8 to block 4.12 are repeated for the next protocol register. If there are no more protocol registers in the port listeners list, then this means that the port listener has provided the incoming connection to each of the protocol registers associated with the port listener in turn, and that none of the protocol registers have accepted the connection. In this case, the port listener declines the connection, at block 4.16. The connection is then terminated.

Returning to block 4.18, assume that a protocol register has accepted a connection. For example, in Figure 2, an incoming connection may have been a GET request in HTTP, in which case the HTTP (web) register 32 recognises the request, and accepts the connection. What is then required is that the protocol register which has accepted a connection is then able to route a connection to an appropriate application providing a service to which the connection relates.

This is performed at block 4.20. More particularly, the protocol register passes the accepted connection to the applications registered therewith in turn, to see if any of the applications are prepared to accept the connection. If an application accepts the connection, then the connection is made. On the other hand, if none of the applications accept the connection, then the connection is rejected at block 4.22. In this case, the protocol register 32 informs the port listener that it should decline the connection.

With the above arrangement, therefore, in the second example embodiment a single port listener is provided for each transport layer end port. The port listener communicates with a protocol aware layer, which acts as an interface layer between multiple applications providing multiple services which make use of the same application layer protocol, and hence the same transport layer end port. However, by providing the protocol aware layer to act as a thin layer between the applications providing the services and the port listeners, contention between applications for use of a port can be avoided.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that by having a listener listen to data connections at the port, and then routing data connections to the applications via the protocol registers, contention is reduced or removed entirely. This is because there is no need to have application- specific listeners for each application. Instead, knowledge of the applications can be maintained in the protocol registers.

Another technical effect of one or more of the example embodiments disclosed herein is that by having a single port listener associated with a port contention is removed completely, as only the single listener monitors the port.

Another technical effect of one or more of the example embodiments disclosed herein is that by maintaining plural protocol registers for at least one application layer protocol, each protocol register relating to a type of service provided by an application which makes use of the associated protocol. This allows for different protocol registers to maintain lists of applications by service provided thereby, even though they may use the same application layer protocol. For example, both web services and UPnP use the same application- layer protocol, HTTP, but provide very different types of service to the end- user. This difference can be reflected by having a protocol register for each of the different services, and allows an application to be registered with the protocol register associated with the application layer protocol used by the application and corresponding to the type of service that the application provides.

Another technical effect of one or more of the example embodiments disclosed herein is that the protocol aware layer has some knowledge of the application layer protocols. Each protocol register is able to decide whether data in a received connection is in accordance with the application layer protocol with which it is associated, and hence whether the connection should be accepted and passed up to the applications registered therewith..

Another technical effect of one or more of the example embodiments disclosed herein is that passing a connection from a port listener at which it is received to the protocol registers associated with the port in turn allows the data in a received connection to be examined in turn by all of the protocol registers, to see if it should be accepted.

Another technical effect of one or more of the example embodiments disclosed herein is obtained from passing data from a protocol register to each of the applications registered therewith in turn until an application accepts the data, or all applications have declined the data. In particular, as there may be several applications registered with a protocol register, it is preferable to allow each of them a chance to accept the connection in turn. In this way, the presence of the protocol aware layer does not prevent an application from accessing a port which it requires; instead, the application has access through the protocol aware layer.

In an example of the invention the connection is a connection of a type corresponding to one of the following transport layer protocols: TCP, UDP, RSVP, and SCTP. In an example of the invention the application layer protocol that is used is one or more protocols selected from the list comprising: HTTP, HTTPS, SMTP, POP3, NTP, RTP, SIP, TELNET, IRC, IMAP, DNS, Gopher, DHCP, TLS, SSL. Of these different types of protocols HTTP over TCP is particularly prevalent.

A further example of the invention provides a computer program or suite of computer programs so arranged such that when executed by a computer it/they cause the computer to operate in accordance with any of the examples described above. Another example of the invention provides a computer-readable storage medium storing a computer program or at least one of the suite of computer programs according to the previous example. The computer readable storage medium is any storage medium known in the art, such as a HDD, solid state memory such as Flash memory, RAM,

ROM, or disc based media.

If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above- described functions may be optional or may be combined.

Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

Claims

1. A method, comprising: receiving data connections addressed to a port at a port listener associated with the port; maintaining, for an application layer protocol, at least one protocol register having a list of applications providing services which use the application layer protocol; and routing received connections from the port listener to said applications via said at least one protocol register; wherein contention for access to transport layer end ports in a host device is reduced.

2. A method according to claim 1, wherein there is a single port listener associated with a port.

3. A method according to claims 1 or 2, wherein the maintaining comprises maintaining plural protocol registers for at least one application layer protocol, each protocol register relating to a type of service provided by an application which makes use of the associated protocol.

4. A method according to claim 3, wherein an application is registered with the protocol register associated with the application layer protocol used by the application and corresponding to the type of service that the application provides.

5. A method according to any of the preceding claims, wherein the routing comprises: passing a connection received at a port listener to the or each protocol register associated with the application layer protocol to which the port relates; parsing at a protocol register the data packets of a received connection to determine if the data contained therein is in accordance with the application layer protocol associated with the protocol register; and accepting a received connection in dependence on results of the parse.

6. A method according to claim 5, wherein a connection is passed from a port listener at which it is received to the protocol registers associated with the port in turn until a protocol register accepts the connection or all protocol registers have declined the connection.

7. A method according to any of the preceding claims, wherein the routing further comprises passing data from a protocol register to each of the applications registered therewith in turn until an application accepts the data, or all applications have declined the data.

8. A host device for one or more applications providing services, the host device comprising: an application layer having one or more applications providing services to users; and a transport layer having a plurality of end ports through which data streams to and/or from said applications pass; said device further comprising: one or more port listeners, each associated with a particular port of the transport layer; and a protocol aware layer comprising one or more protocol registers, each protocol register being associated with an application- layer protocol and having a list of those of said applications providing services which make use of said application-layer protocol, the arrangement being such that a data connection received at one of said ports is routed to an application in the application layer via one of said protocol registers.

9. A host device according to claim 8, wherein there is a single port listener associated with a port.

10. A host device according to claims 8 or 9, wherein for at least one application layer protocol there are plural protocol registers, each protocol register relating to a type of service provided by an application which makes use of the associated protocol.

11. A host device according to claim 10, wherein an application is registered with the protocol register associated with the application layer protocol used by the application and corresponding to the type of service that the application provides.

12. A host device according to any of claims 8 to 11, wherein in use said port listeners pass received data connections to the or each protocol register associated with the port, and said protocol registers parse the data received in the data packets of a connection to determine whether said data is in accordance with the application-layer protocol; wherein a protocol registers accepts a connection in dependence on the results of the parse.

13. A host device according to claim 12, wherein a connection is passed from a port listener at which it is received to the protocol registers associated with the port in turn until a protocol register accepts the connection or all protocol registers have declined the connection.

14. A host device according to any of claims 8 to 13, wherein the or each protocol register passes data from a data connection to each of the applications registered therewith in turn until an application accepts the data, or all applications have declined the data.

15. An apparatus, comprising: at least one processor; and at least one memory including computer program code the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform at least the following: receive data connections addressed to a port at a port listener associated with the port; maintain, for an application layer protocol, at least one protocol register having a list of applications providing services which use the application layer protocol; and route received connections from the port listener to said applications via said at least one protocol register; wherein contention for access to transport layer end ports in a host device is reduced.

16. An apparatus according to claim 15, wherein there is a single port listener associated with a port.

17. An apparatus according to claims 15 or 6, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to maintain plural protocol registers for at least one application layer protocol, each protocol register relating to a type of service provided by an application which makes use of the associated protocol.

18. An apparatus according to claim 17, wherein an application is registered with the protocol register associated with the application layer protocol used by the application and corresponding to the type of service that the application provides.

19. An apparatus according to any of claims 15 to 18, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to: pass a connection received at a port listener to the or each protocol register associated with the application layer protocol to which the port relates; parse at a protocol register the data packets of a received connection to determine if the data contained therein is in accordance with the application layer protocol associated with the protocol register; and accept a received connection in dependence on results of the parse.

20. An apparatus according to claim 19, wherein a connection is passed from a port listener at which it is received to the protocol registers associated with the port in turn until a protocol register accepts the connection or all protocol registers have declined the connection.

21. An apparatus according to any of claims 15 to 20, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to pass data from a protocol register to each of the applications registered therewith in turn until an application accepts the data, or all applications have declined the data.