🚀 go-pugleaf

>} Harald:
>}
>} Hi.
>}
>} Using the RFC-1006 encapsulation of TP4 in TCP one should use port 102.
>}
>} --jon.
>}
>} Harry:
>
>}
>} Ok.  We will deassign ports 103 and 104.  Thanks.
>}
>} --jon.
>
>I am concerned that some early implementations cannot multiplex port
>102 to handle RFC1006 traffic for more than one application.
>In particular, the ARGO X.400 implementation that we are using needs a
>dedicated port for X.400 RFC1006 traffic.  I do not know how many
>other existing implementations have this problem.  I would like to see
>at least one port reserved for X.400 (103 or 104).
>
>allan

Jon,

I support Allan's view on that point. You must consider that most
implementations of RFC-1006 are done by user level "filters" above a TCP
connection; I dont know of any "kernel" implementations, that would provide
e.g. an RFC-1006 socket. In fact, one could expect that system programmers
would rather try to implement "the real thing", i.e. TP-4. Multiplexing all
RFC-1006 trafic can thus only be done (on UNIX) in one of two ways:

1) have a process listening on port 102, let it "fork" a child process for
every new connection, redirect the incoming TCP stream to some predefined "file
descriptor", and "exec" a particular program selected by the Transport Selector
of the RFC-1006 header. This is what the ISODE listener does; it will not work
for "single process" applications, which must handle several connection in
parallel. It also implies that the a new process must be completely initialized
for each connection, which does not enhance the response time.

2) When several "single process" applications are running on the same host, one
likes to allocate a separate TCP port for each of them, so that they can at any
time wait for new connections + new messages, e.g. using "select". If this
cannot be done, one has to implement a "demultiplexing" process, which will
wait for connections on port 102 and redirect the RFC-1006 messages to the
server processes by using some local IPC; one consequence is that two
processes will have to be awakened for each and every packet, leading to
noticeable losses in performances.

I know that several implementations use the second solutions, picking up port
numbers "semi-randomly": EAN (X.400 from UBC) use port 8006; M.PLUS (X.400 from
INRIA) uses port 3456; PIZARRO (X.500 from INRIA) uses port 5678, etc. Indeed,
all these numbers can be parametrized. Allocating reasonable port numbers would
at least enable network administrators to correlate TCP traffic with ISO
applications.

May I suggest that you do not deallocate the ports 103 and 104, and that one of
them be allocated to X.400 and the other to X.500? In fact, I could even use a
few more ports, e.g. for FTAM and CMIP...

Best regards

Christian Huitema