Browse Prior Art Database

Communications architecture to support massively connected Containers

IP.com Disclosure Number: IPCOM000010127D
Original Publication Date: 2002-Oct-24
Included in the Prior Art Database: 2002-Oct-24
Document File: 6 page(s) / 56K

Publishing Venue

IBM

Abstract

The GRID has recently become a popular area of investigation and means different things to each observer. In the broadest sense we can identify the need for 'containers' in which work will be run on behalf of 'principals' in whom we place varying degrees of trust. The GRID is formed by connecting together some number of these containers and adding in whatever is necessary to support client connection into the resulting network. As work is injected we can assume that connections will begin to be formed between containers and we might assume that eventually each container will be connected to all the others. As the number of containers rises the number of connections thus becomes extremely large and is an important design issue in the implementation of any practical container.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 17% of the total text.

Page 1 of 6

Communications architecture to support massively connected Containers

The GRID has recently become a popular area of investigation and means different things to each observer. In the broadest sense we can identify the need for 'containers' in which work will be run on behalf of 'principals' in whom we place varying degrees of trust. The GRID is formed by connecting together some number of these containers and adding in whatever is necessary to support client connection into the resulting network. As work is injected we can assume that connections will begin to be formed between containers and we might assume that eventually each container will be connected to all the others. As the number of containers rises the number of connections thus becomes extremely large and is an important design issue in the implementation of any practical container. There are two obvious solutions to the problem. We could build some form of connection pool and then provide some management layer which maintains a pool size limit by sharing connections and by closing and reopening the least used ones in some manner transparent to the users. Alternatively we could attempt to support very large numbers of connections. Both approaches have their problems but the latter approach was the one chosen.

    If we choose to base our communications on TCP/IP then we would soon run out of resources in the underlying operating system. Typically the OS imposes strict limits on the number of sockets available on the machine and this number is a build time constant which controls the allocation of memory buffers within the OS. Hence we would soon reach the limits of the operating system and fail. There are other problems with TCP/IP since it is possible to mount a denial of service attack on TCP/IP sockets by firing SYN packets and thus consuming resources which prevents other users connecting. Most operating systems now have approaches for dealing with these SYN attacks but these measures are often absent from 'low end' operating systems such as found on mobile phones. If we want to produce software which could run in these environments it would be an advantage to develop a communications layer which concentrated on preventing attacks on all platforms. Efficiency is another consideration. The standard Java* support for TCP/IP involves a server socket from which the user must accept a communicating socket. This leads to an architecture in which there is a thread per connection. Since most platforms provide a relatively low number of threads this is another significant limitation on scalability. Java 1.4 introduces the concept of a SelectableChannel which allows a single thread to wait for multiple sockets at once. This approach is a big advantage but of course it doesn't avoid the fact that there is still a limit on the total number of sockets imposed by the underlying OS. Hence the challenge is to produce an architecture which supports very large numbers of connections with...