Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Sharing a Single TCP/IP Daemon Among Multiple, Unrelated Functions

IP.com Disclosure Number: IPCOM000011965D
Original Publication Date: 2003-Mar-27
Included in the Prior Art Database: 2003-Mar-27
Document File: 2 page(s) / 50K

Publishing Venue

IBM

Abstract

Disclosed is a software design which allows multiple, unrelated functions within a software system to share a single daemon (server socket) for accepting incoming socket requests. Local functions which need to accept incoming socket requests register with the single daemon and provide a unique identifier. When an incoming socket request is received by the daemon, the daemon first reads the unique identifier from the socket. The daemon matches the identifier from the socket with the registered functions and passes the socket to the local function with the matching identifier.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Sharing a Single TCP/IP Daemon Among Multiple, Unrelated Functions

   One of the more common ways for communicating between remote systems or local operating system processes is to create a TCP/IP socket connection between them and use the socket for sending information. However, before any socket connection can be created one of the remote systems (or processes) must have a daemon running which creates a server socket and listens on a port for the other remote system to connect to.

With large scale software applications there are often many local functions that are handling communications with other local processes or remote systems using sockets. This can lead to:

1. A proliferation of threads. Each function creates an additional thread (to run the server socket) which blocks waiting for incoming socket requests.

2. Wastes operating system resources such as threads, TCP/IP ports and memory.

3. Often each function provides its own user interface for changing the port number which makes it confusing for the user to configure. Having multiple ports also makes it difficult for network administrators to configure firewalls which allow all the different ports to be accepted.

4. Redundant software development effort to code the server sockets and the user interface for changing the ports.

This disclosure outlines how a single daemon which listens on a single TCP/IP port can be used to accept incoming socket requests for all local functions, instead of each function having it...