Allan.Cargille@pilot.cs.wisc.edu (Allan Cargille) (12/11/90)
} 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 -- Allan Cargille Computer Sciences Department Associate Researcher University of Wisconsin-Madison Fax +1 (608) 262-9777 1210 West Dayton Street Voice +1 (608) 262-5084 Madison, WI 53706 USA cargille@cs.wisc.edu uwvax!cargille X.400 C=us; ADMD= ; PRMD=xnren; O=uw-madison; OU=cs; S=cargille
harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (12/11/90)
I know that at least two other implementations, - EAN - M.PLUS have the same problem, that is, they cannot be started by a daemon at port 102. What is required to have the 103 port reassigned for this function (X.400 over RFC1006)?
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (12/11/90)
>} 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
vcerf@NRI.Reston.VA.US (12/12/90)
Jon, didn't we run into a similar situation on the ARPANET when we assigned links 155-158 for IP even though,in the end, we only dedicated 155 for the operational traffic? If the ports have not been reassigned, perhaps it is not a big deal to assign one additional one, again? Vint
vcerf@NRI.Reston.VA.US (12/12/90)
Allan, can't the early implementations get fixed? Vint