The InnovationQ application will be updated on Sunday, May 31st from 10am-noon ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Handling multiple distinct protocols through a single connection listener

IP.com Disclosure Number: IPCOM000015068D
Original Publication Date: 2001-Sep-16
Included in the Prior Art Database: 2003-Jun-20

Publishing Venue



It is usually the case that to make a connection from a client to a server, using a port-based protocol such as TCP/IP, the connection is made to a specific port on the destination server, and it is pre-arranged that a server, capable of understanding the protocol used by the client, will be listening on that port to receive and interpret the protocol stream off the wire. This can cause administrative problems, since both parties must know in advance which application is listening on which port of the server. For "well known" applications, this is standardised by IANA port registration, so for example, it is expected that the service on port 80 of a server will be able to understand the HTTP protocol. However, for not-so-well-known applications, this can be more of a problem. This disclosure provides a mechanism for a single server application to identify and interpret multiple protocols received through the same port. This means that for the class of applications supported by this mechanism, only a single port number needs to be known for any given server. Any client which talks any of the supported protocols of this service will be able to connect successfully to that port and have their protocols interpreted correctly. The invention relies on an identifiable "eye catcher" in the first few bytes of a protocol stream when a connection is first established. In, for example, the case of IBM's MQSeries* messaging product, this is "TSH" in either ASCII or EBCDIC. For HTTP, it would be one of "GET/POST/HEAD" (or a couple of other possibilities). The listener program contains a pre-configured table of these eye-catcher strings. When a new socket connection is received from a client over the network, the first few bytes are read from the socket, one-by-one, and a character-by-character match is performed against the eye-catcher lookup table. (Note that this may be stored in a tree-structure to provide a more efficient search). If the eye-catcher of a supported protocol matches completely, then the listener program calls or invokes an instance of the service associated with that eye-catcher, which will then continue the conversation with the remote client. (Note that a buffering mechanism is required to re-attach the eye-catcher string to the front of the message stream, otherwise the service will not recognise the protocol it has been handed). If there is no match in the eye-catcher table, then the listener program closes the socket, as the client is using a protocol which is not supportd by this listener. It is only the first message of the client-server session which has to display the eye-catcher thereafter, the socket is firmly associated with its back-end service, and the listener program has no further interest in the protocol flow, apart from continuing to ensure that the data packets reach the back-end service (exactly how it does this depends on the relationship between the listener and the back-end protocol handler, and the manner in which the back-end service is invoked). It should be noted that some existing protocols do not have this unique, distinctive "eye-catcher" on the front, so it would not therefore be possible to include such protocols in the list of protocols supported by this mechanism. IBM and MQSeries are trademarks of International Business Machines Corporation in the United States, other countries or both