Ascert X.25 Library for Java


Introduction

The Ascert X.25 Library for Java provides a common API for Java applications to control and communicate with remote applications over X.25 connections.

Javadoc API documentation for developing applications using the library can be found here.

If you're not a Java developer, or you're not sure what X.25 is, then this library is probably not for you!

Licensing

This library is OSI Certified Open Source Software, provided under the terms of the Common Public License.

Support

The toolkit is provided on an "as-is" basis with no warranties of any kind and no support included. Ascert may release newer versions as enhancements and fixes are found, and is always glad to receive comments and feedback. No commitment is given, however, as to when or whether specific requests may be reviewed and/or implemented.

If your organisation finds the library useful enough that you'd rather be covered by a commercial support agreement, then Ascert would be happy to provide quotations for various levels of support contract.


Change Log

Version 0.3.0

   Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x77F53741
   Function=RtlQueryInformationActivationContext+0x223

Version 0.2.0

Version 0.1.0


Possible Enhancements

As with any piece of software, there are always more things you'd like to do than time available in which to work on them. This library is no exception.

In it's present form it gives basic but workable access to the most commonly used X.25 features. Ideas on some of the more significant areas where it could be enhanced or improved are described in the sections below.

If you look at the source code, don't be surprised if you also find a few //TODO markers. These don't necessarily signify areas which don't work, just thoughts on how things could be done differently or perhaps better as the code was being written.

For some limitations, it's probable that attempting to improve them should be left until additional driver implementations are needed since, for the most part, they don't present real limitations when using the existing FarSync driver.

Operation timeouts

The standard Java TCP socket handling classes provide timeouts for a number of blocking operations such as connect, accept, recv etc. These do provide a certain level of convenience, but at the expense of some not very nice, highly platform specific code at the JNI level. In general, Java's multi-threading seems to offer a way to program without a need to resort to timeout's e.g. by using separate threads for blocking operation vs. socket control. Hence, at this stage timeout handling has been deferred until such time as there is a need for it which cannot be accomodated with an alternative approach.

Non blocking I/O support

Since JDK 1.4, Java has had support for non-blocking i/o operations. At first glance this may seem a worthwhile addition for the X.25 library. However, the following points were considered in making a decision not to include support for this in the initial version.

Against this, the benefits for non-blocking i/o are harder to argue. Non-blocking i/o doesn't necessarily improve the performance for the majority of applications, in fact quite the reverse. The system cost of the additional select() polling can actually worsen performance. So why did Sun bother to add non-blocking i/o at all? Well, for server applications dealing with massive (read: tens of thousands) of TCP sockets, non-blocking i/o reduces the overhead on finite system resources such as threads, thread memory, and thread management locks. However, most servers have a limited number of slots in which they could accommodate X.25 cards, and each X.25 card will have a limited number of virtual circuits it can support (usually in hundreds). So the case for adding non blocking i/o for TCP sockets doesn't necessarily stack up as a case for adding non-blocking i/o support for X.25.

Socket Closedown

At present, proper socket closedown is left to the application using the library, which is perfectly reasonable and valid. However, errant applications which don't close down will tie up resources and possibly prevent restarts. It's conceivable that this could be enhanced to allow the application developer to delegate responsibility for clean-up to the library, which could attempt to close and cleanup all sockets. In practice, this might be tricky to co-ordinate i.e. preventing the libraries cleanup code getting in before the application has finished it's own tidying up.

Better Facilities abstraction

At present, only raw facilities can be supplied in a buffer which must conform to the X.25 standards for facilities formats. This is both a poor abstraction, and also potentially an area where driver implementation specifics could bleed into application code e.g. some drivers may use a higher level interface for getting and setting facilities which is not compatible with this approach.

It would be relatively straightforward to add an X25Facilities class in which facilities could be set and/or retrieved, and then make the driver implementations responsible for mapping this to suitable low level driver interface calls.

Better physical assignment abstractions

It's very useful to be able to tie specific X.25 operations such as making and accepting calls to specific X.25 lines. A very simple String specifier is used at present to provide the line assignment qualifier, which could create driver implementation dependencies if application developers do not code carefully how line assignments are set and passed through to the library.

PVC abstraction

Again, the current PVC abstraction is workable but simplistic and could be improved to remove possible driver dependencies.

InputStream and OutputStream variant classes

These would be fairly trivial to add, but also may be of limited use since X.25 is not a stream based protocol. The biggest drawback in implementing them will be whether (and how) to map M-bit handling in a useful way onto the standard Stream based classes.


Acknowledgements

Ascert is pleased to acknowledge the following projects, organisations and individuals who's tools have been used in the creation of this software: