This directory contains the work on mapping the X-Protocol onto the ISOTranport Service.It is based on X11 R3 and ISODE Relase 6.0 tsap libraries.Basically, we require to build a server that Listens on well knownT-SAPs. We then need clients that connect to this server.server/contains a libos for building an X server with (this directorycontains a Makefile to build such a server for a Sun at UCL).These would replace the routines in ..../X11/R3/server/os/4.2bsd/(for example)client/contains the OS/Comms parts of Xlib, and so clients can be re-linkedwith the .o files here before Xlib, to force the right thing tohappen.These would replace the relevant routines in .../X11/R3/lib/X/...although in both cases it is simpler to change the Imakefiles or Makefiles just to pick up the .o's from here prior to searching the standard libraries...-DISOCONN  in either, builds ISO T-Service usage in client and serverI would *NOT* advise defining TCPCONN or UNIXCONN or DNETCONN as well,but the code is sort of there...client: server:so as we have an array of transport I/O fns and init it in _XConnectDisplay in XConnDis.c and inCreateWellKnownSockets in connection.c appropriate for DECNET/TCP or ISO TPTHIS HAS NOT BEEN TESTED in SERVER, only for clients...Done this by:Add array of a read(v), write(v), connect, listen, accept, closefunctions ptrs, which are used byTWrite(v)To[Server|Client]TRead(v)From[Server|Client]TConnectTListenTAcceptTCloseDownwell sort of...Note that TNetAccept will function for select as well as ISO TP so we dont need a fn for that...-DISODEBUG adds lots of fprintf(stderr...) for me.[if the variable isodexbug is set to TRUE in connection.c/XConnDis.c]I use isodetcpath to get my own isodetail/isoentities file. Ina proper installation, this aint necessary, but UCL has a weirdsetup:-)Note, ISO Server names are HostName:T-Name:DisplayNumberwhere T-Name is X or T to distinguish T/N service from TCP and DECNETThus xhost must needs be changed, as must the rest of the accesscontrol stuff.So you could do a setenv DISPLAY `hostname`:X0 or what have you. Note, because we do an AEI lookup on name + TServiceDisplayNumber, we dont have to do the atoi stuff on display numbers for ISOCONNS...they would be separate AEI entries in isoentities or directory.(server/)access.c,connect.c and (client/)XConnDis.c containreferences to sockadd_in structs all over the place for working outpeers and doing access control. These are changed to be TSAPaddrstructs. Lenghts for authenitication of clients are the first NASIZEworth of the NSAP part of the TSAP...this is by analogy with doin iton the IP (i.e. per host) addr only...The parse of HostName:T-NameDisplayNumber goes straight into a callto str2aei(HostName, T-Name+DisplayNumber). So you nneed  an entryin your isoentities or directory!!T-Name = X or T at the moment.i.e. xterm -display perky:X0The entry in isoentities looks like:## X Server (use Internet + X_TCP_PORT + 1 for now# The OID Is really one of Surreys at the mo!!# I guess OIDs for X should be done properly sometime...#perky		T0		1.17.4.3.36.1.1 \		Internet=perky.cs.ucl.ac.uk+6001dir		X0		1.17.4.3.36.1.3 \		Janet=00000511320041		#The mapping:X uses non-blocking writes, reads. The Open/Close aresynchronous/blocking. A particular problem may lie in the nature of reliable close in DECNET and TCP, but unreliable close in ISO TP, so we really ought to use session; in fact, there's a lot of debate, but ideally,we would map the req/reply nature of X onto Remote Operations (which,contrary to popular belief, will do the streaming required by X).X doesnt use async (SIGIO) as far as i could find, luckily for me!!Unfortunately, the X Request/Response and Presentation functionalityis spread throughout the X library and DDX code, which makes thisapproach a real headache.But, for now, its easier to do a transport mapping, and it buys us alot, such as X over TP/X.25 and, through a TSB, between X.25 nets andTCP/IP nets, at low software effort. routines that have changed:From ddx/libos stuff (based on 4.2bsd version)server/access.cconnection.cWaitFor.cio.cFrom Xlib stuffclient/XConnDis.cXlibInt.cXlibint.hXlibos.h1.socket+bind+connect=>TConnRequestQoS is set low for fun, and tsdu size is set to ethernet frame size (idont understand why i did this!!).2.socket+bind+listen=>TNetListenSince an X server can handle multiple clients, we use the *static*server model, rather than the tsapd model.3. accept=>TNetAccept (blocking...) plusTInit, TConnResponse4.read/write and readv writev go over to beingTReadRequest/TTDataRequest and TReadRequest/TWriteReqest respectively5.In the client, Xlibos.h defines macros for BytesReadable, WriteToServer, ReadFromServer, WritevToServer, ReadvFromServer.These map onto BytesReadable, TWriteToServer, TReadFromServer, TWritevToServer, TReadvFromServer.which are arrays of routines (currently [2]) indexed by the IO Family (i.e. Unix or ISODE) initialised per X connection to callTSelectBytes, TReadRequest, TWriteReqest etc...or the unix (i.e. original) equivalents...a similar trick is used in the server to achieve backwards compatibility for DECNET and raw TCP access...Since a TReadRequest returns *all* the buffered data in the transport connection, the TRead(v)FromServer routines must hold onto extra data beyond the X requested amount for later calls...This is a little horrid...6.The select loop in server in WaitFor.c goes to aTNetAccept loop, checking fora) new connectionsb) writablesc) readableswhich cause scheduling actions in the server.NB select can poll for much shorter times than TNetAccept which maycause stickiness in X performance...7.getpeername=>TGetAddressesFinally, we have to map from ISODE back to X. Since all the tsaproutines can return a disconnect with a reason, but (4.2bsd)X expects errno's to be meaningful, we should map the DR_*s tosensible errno's. In most cases (e.g. TService over TCP) this willprobably happen anyway...***********************WARNING*******************************This has not been extensively tested. It is a sort of existence proofimplementation rather than a proper port. I have tested it underSun OS 4.0 on a Sun 3/60C and a Sun 4/330, using ISODE Release 6 beta,with TService over TCP and over Sunlink X.25 6.0 and over raw TCP! I havnt tested any X clients other than theones with subdirectories here! I have *not* checked that undefing ISOCONN makes a good old R3TCP/UNIX/DECNET lib, and i have not bothered merging in the hpuxor CRAY ifdef'd stuff, since we run BSD4.3 on our HPs, and dont have COS on our two Crays...The Makefiles are lazy simple minded peasantish and so forth...***********************WARNING*******************************jon crowcroft--------------------Addendum------------------------MakeAClient - how to make *a* client at UCLMakeAServer - how to make *a* server at UCLMakefile* - somethin that does all the aboveREAD-ME - what you are doing nowTODO - what i should be doing nowbin/ - where i put themclient/ - the client specific partsideas/ - some notes from friends../isode@ - a link to the future../isodetail/ - my (Bond Street) tailorserver/ - the server (dix/os) specifixtsap/ - another link to the futureuwm/ - where i make uwmxclock/ - and a clockxedit/ - and something big with widgetsxhost/ - a not quite there yet ISO auth note this is the only client that actually requires source changes ...xinit/ - where i make my beginingxmag/ - Room for a viewxterm/ - terminal emulation (what zombies do)xwininfo/ - and just one more client to check[Currently, this code all derives from the X11R3 OS/Comms 4.2BSDspecific code, so i guess the MIT/X Consortium Copyright shouldremain...perhaps with an ISODE one added. I certainly dont care to putmy name to it :-) The reason for this was i was hoping we could run a rawTCP+DECNET+T-Service multiprotocol X service...so i tried to make allthe changes additions rather than substitutions for existing X code.This may be misled, but it worked for Julian Onions in his NTPport...and would admit of a first cut on an X/ISODE to X/TCP a(e.g.when shared X comes along...) - howz that for a boggle?Also, some path names are grotty, and need Xizing, or ISODEizing -again that is due to UCL weird installation]Jon Crowcroftjon@cs.ucl.ac.uk              internetjon@uk.ac.ucl.cs              JANETc=gb@o=University College London@ou=Computer Science@cn=Jon Crowcroft The Matrix