rick@pcrat.uucp (Rick Richardson) (12/08/89)
It appears that the major UNIX players on Intel 80[34]86 hardware are all represented in some way or another in these forums. In alphabetical order, and at the risk of forgetting someone, you are AT&T, Dell, Everex, Intel, INTERACTIVE, SCO, and Sun. I'd like to raise an important issue before you all step off and start delivering UNIX SVRV.4 on Intel hardware prematurely. In UNIX SVR3.2 no standard exists for a client to connect to a local X server. Clients which are compiled with one vendors X windows libraries and toolkits cannot make a local IPC connection to another vendors X windows server. Because of this, it is impossible to generate one binary to run in all SVR3.2 UNIX environments. Note that I am speaking of local connections only -- network connections appear not to have this problem. The bottom line is that there is no such thing as a "shrink wrapped" UNIX SVR3.2/X11.3 application. In SVRV.4 we now have a standard GUI for the first time in UNIX. I would like to see this standard GUI live up to the expectations of both software developers and end users of 80[34]86 hardware. Can you vendors please have a meeting of the minds? You folks *must* agree on the mechanism(s) to be used by local clients when connecting to a local server. It's too late for SVR3.2. Don't repeat the mistake in SVR.4. Rick Richardson President PC Research, Inc. (201) 389-8963
plocher@sally.Sun.COM (John Plocher) (12/14/89)
+-- In <1989Dec8.005923.23810@pcrat.uucp> Rick Richardson writes | In UNIX SVR3.2 no standard exists for a client to connect to | a local X server. | You folks *must* agree on the mechanism(s) to be used by local | clients when connecting to a local server. It's too late for | SVR3.2. Don't repeat the mistake in SVR.4. +-- As one of the team delivering the Sun X11/NeWS server source to AT&T for the Vr4 source tape, I feel I can comment on this issue with a bit of authority. Nevertheless, this posting is NOT an official statement by Sun or AT&T. Caveat Emptor. :-) The 3.2 world is an ungodly mess when it comes to this problem; I agree with Rick here, it is almost beyond hope. One workaround may be to set DISPLAY=localhost:0 and force the client to use the loopback network interface for connections to the server. Slow, but faster than not working at all :-) Using the above method will only work IF THE NETWORKING LIBRARIES on the systems ARE COMPATABLE. Since networking is also not a standard, you can't even move clients that use networking between systems! For remote clients, the picture is consistant: The Vr4.0 AT&T XWIN server uses a connection method based on TLI and nameserver daemons which (on an ethernet, but not starlan) gets mapped to a TCP/IP connection to port 600x on the server. Other X servers implement a socket emulation library and graft that directly onto the X code from MIT which again talks to the TCP/IP port 600x on the server. When you get to local clients, the picture changes a lot: XWIN and X11/NeWS use ptys to do local connections; other servers use Unix Domain sockets; still others use shared memory. The libraries are usually statically linked to the clients, so that there is no way to modify them without the source. Vr4 won't necessarily solve the problem of systems using different local connection methods; it WILL, however, - make the networking interface standard (TLI with a socket emulation library on top of it) - make the libX11 XLib library DYNAMIC This means that AT&T can use their XLib, ISC can use theirs, and Everix can go their way; clients are developed as usual except that they are dynamically linked to libX11. This is a win when you realize that the library that the client actually uses is the one provided with the server that is resolved at run time! -John Plocher
guy@auspex.UUCP (Guy Harris) (12/15/89)
>You folks *must* agree on the mechanism(s) to be used by local >clients when connecting to a local server. It's too late for >SVR3.2. Don't repeat the mistake in SVR.4. Or, alternatively, put the code that does the connection (which presumably means Xlib) into a dynamically-linked shared library and require that it be linked to dynamically, so that the code that does the connection doesn't appear in shrink-wrapped binaries.
vjs@calcite.UUCP (Vernon Schryver) (12/17/89)
In article <129232@sun.Eng.Sun.COM>,plocher@sally.Sun.COM (John Plocher) writes: > ... > One workaround may be to set > DISPLAY=localhost:0 > and force the client to use the loopback network interface > for connections to the server. Slow, but faster than not > working at all :-) How slow is that? That is, how does the loopback interface perform on common 386 UNIX'es, measured either by something in X said to be nasty like ico, or a pure TCP/UDP measure like TTCP, but <<not>> FTP, since I'm asking about the network and not the file system. Fast workstations (e.g. based on MIPS or SPARC) get 1.5-2.0 MByte/sec thru TTCP via loopback. I've been told WIN TCP on a 386 clone gets a respectible >300KByte/sec thru TTCP on an ethernet. How do it and the others do via loopback? Since no real I/O is involved, this is a measure of how much overhead is in the TCP implementation, as well as how fast the CPU can bcopy or otherwise shuffle bytes, as well as other stuff like the scheduler. I would be happy to mail anyone who can't FTP from BRL or the other places a copy of ttcp.c. It is supposed to appear in comp.sources.unix someday. > ...[distressing but no doubt accurate description of the state of the > i386 network world deleted]... > This is a win when you realize that the library that the client > actually uses is the one provided with the server that is resolved > at run time! How much will/does Sun/SVR4-style dynamic linking cost in performance? I've heard rumors ranging from 3% to 15%. What are real numbers, in a variety of situations? Vernon Schryver vjs@calcite.uucp
guy@auspex.UUCP (Guy Harris) (12/19/89)
>Vr4 won't necessarily solve the problem of systems using >different local connection methods; The Transport Independent RPC white paper from Sun makes reference to a "loopback" transport; if this is present on all flavors of S5R4, it could potentially be used for this (I suspect it's sort of a TLI moral equivalent to UNIX-domain sockets). If somebody decides to use some other transport, e.g. shared memory, that can still work, though, if (as you imply) they made "libX11" dynamic.