Conference bulova::decw_jan-89_to_nov-90

    Previous notes have indicated that there is a fixed limit of 32 
    connections.
    
    				Steve

The limit of 32 connections to the server is hard-coded.  There is no
way that I know of in the X architecture to retrieve this number.

I am thinking of raising this limit in a future version of DECwindows.

One application opening up 100 separate connections sounds like a very
strange thing todo.  Even a single connection can create lots and lots
of windows.  What does your application do that requires so many 
independent connections?

    	
    
        We  use the XTalk phylosophy to link various processes using
    	X. Thus we are able to transmit locally  in realtime information 
    	needed to update screens. 
    	The whole task monitoring can be done by X! We have extended the
        toolkit to be able to  handle via callbacks Interclient
    	communication.
        We plan to use more than 32 workstations. Would be very happy
        to see the limit raised.
    
        What about this limit in MIT release 4?
    
        What about DecWindows integration of MIT release 4 features?
    
     		thanks.

    

>        We  use the XTalk phylosophy to link various processes using
>    	X. Thus we are able to transmit locally  in realtime information 
>    	needed to update screens. 
>    	The whole task monitoring can be done by X! We have extended the
>        toolkit to be able to  handle via callbacks Interclient
>    	communication.
>        We plan to use more than 32 workstations. Would be very happy
>        to see the limit raised.

Are you saying that you use a single X server to pass information between
32 different workstations?  I am not familiar with XTalk.

What limit would be acceptable for your design?

>        What about this limit in MIT release 4?
    
The limit is in OS-dependent code, so it has nothing to do with the MIT
release number.  I don't know what the limit is on Ultrix.

>        What about DecWindows integration of MIT release 4 features?

Which features are you interested in?  We can't integrate them all in
(not enough time), but we will certainly consider critical ones.

The number of connections to a server is very system-dependent.  It depends
entirely on the underlying OS.  In Ultrix currently, it is 61 
(64 - 3 reserved file descriptors), I think.
				Jeff

I'm confused.  Are there 100 X servers and 1 X client,
or 100 application servers which are really X clients and 1 X server,
or 100 X servers and 100 X clients.

In other words, how many applications programs are there and how many displays
do they connect to and what is the overlay between them.

My guess is that there is 1 client and 100 displays, so each X server only
has 1 connection, but the application need to create 100 connections.

This design worries me because Xlib is very simple minded and assumes that
if you lose a connection to a display, then the application has no way to
recover, so one communication error and the whole thing goes down the tube.
I would guess that for this to work it would be necessary to develop a
really persistent transport; one that would recover from broken comm links
without Xlib and the Xserver knowing it happened.

        MORE INFORMATIONS...
    
        We implement in the Class Part of a VListWidget (Our ListBox)
        a connection to an event-server  ,testing we have only one
    	connection by application.

            Each application needs to know modifications made in a single
    	database in order to refresh its screen in a real_time way.

            The only big problem will be the server falling down.
        Each application can restart whenever you want because we export
    	a LoadCallback permitting to load data only after the connection
    	has been made.In that way modifications are queuing during chargement
    	and will ensure no loss .
        As we work in a real-time trading environment,a lot of users
    	will bring us new data ,and the 32 connections will be quickly 
    	exhausted.
    
        We have no heavy load experience ,some problems might occure
        because architecture is not optimized.We look forward implementing in
    	the future one event-server per workstation;each event-server being
    	in charge of communicating with the network via an other protocol
    	(TCP/IP) .
    
        Best Regards.

I'm sorry, I don't understand your explanation.

I don't think you've answered my questions or Paul's questions.

Please start by giving us your hardware configuration, so we
understand how many workstations (and central processors, if any)
we are talking about.

Please then describe what applications are running on which nodes,
and which nodes each application does an OpenDisplay to.

Please give the maximum number of nodes and connections you expect
the customer will require.

	Hello,

	The configuration is :

		one VAX as RMS shared 'file server',
		five 'operator workstation' (vs3100),
		one vaxstation (vs3100) as 'event server'.

	Each 'operator workstation' uses 1 'xopendisplay' on itself and
	N 'xopendisplay' on the 'event server' corresponding to the 
	(sharelist) the (stockbroker) is following.

	The 'event server' opens a 'xopendisplay' on 'operator workstation'
	for each received 'xopendisplay'.

	The 'event server' is informed by the 'operator workstation' when there
	is a change in the (sharelist) through an x11 event on the corresponding
	xdisplay.It can send an x11 event to inform interested 'operator
	workstation' of the modification. 

	I resume:
		for the 'event server' there is (sharelist) attached to each
	'xopendisplay' received.
		x11 event received on these 'xopendisplay' represents a change
	on this (sharelist).
		the 'event server' sends a x11 event to all 'xopendisplay' it
	opened  on 'operator workstation' for this (sharelist) to inform
	them of the change.

	Data is exchange through ethernet/rms shared files. 

		In fact there are only a few bytes echanged through the x11 
	protocol and real data is exchanged by decnet/rms

    	With this configuration in use (5 stockbroker) 30 input
        xopendisplay on the 'event server' are cuurent.
    
    	imagine with 25 stockbroker ....
    
    		Am i more understandable ?
    
    						Jean-claude.
        

Why not use plain old ordinary DECnet connections to handle the event
notification, instead of X events?  If you did that, you wouldn't need any
X display connections to the "event server," just DECnet logical links, which
are a much more plentiful resource.  Furthermore, you really only need one
connection per stockbroker client, not one per stock.  The client program
connects once to the event server, then transmits to it a list of stocks it is
interested in.  The notification record that the event server transmits when
something has changed contains an identifier for which stock has changed.

X Events are not really designed to be a general network and message-switching
mechanism.

--PSW

Yes, use DECnet task-to-task communication. I have implemented this in a dealing
room with 100 workstations without any problems. All the DECwindows graphics
are done locally on the workstations. The applications on the workstations
have a connection to multithreaded servers on a central machine. I think the
use of X11 over the network is the wrong approach in most cases and stand in
the way for development of *really* distributed systems.

Olav

          Some more explanations: X events can be easily used as a local
	  --------------------------------------------------------------
                            message switching mechanism.
			    ----------------------------

          Preliminary remarks
          -------------------
          We have one single event server client application running on the
          LSE network. Each usual client application connects itself to the
          eventserver client via an XOpenDisplay on a shared X-Server to
          which the eventserver is connected. The eventserver takes note of
          this connection request and responds by an XOpenDisplay on the
          user XServer of the requesting client application. This is the
          logical link created.

          Each single widget on the user's screen channels through this
          logical link its registration to the eventserver. The eventserver
          client application informs each registered widget separately of a
          particular event via an XSendEvent to the user's X-Server. In
          fact, the connection of a widget to an eventserver is to be
          viewed as an application programmer's model. This model offers
          three advantages:

          a. Application programmers care about one task monitor, i.e. the
          XMonitor. This simplifies programming and training. The more
          because we define low level objects as widgets, especially wait-
          ing queues. They are depositary of the information and can be
          interrogated if needed. If some display is needed from the user'
          point of view or for debugging purposes, we can display it. There
          is no more concern about the coherence between application data
          and screen. The application data is displayed through system
          routines.

          b. We can easily define two loosely coupled parts in an applica-
          tion: the part concerned about the display of information and the
          part concerned about actions resulting from a selection of one
          specific item. Display information routines can be reused in
          different applications, action programs are of course application
          dependant.

          c. Through multiple callbacks, it is possible to segment display
          routines very easily in modules concerned about one part of the
          screen. The coupling between the modules exists only via the
          connection to identical events.


          Concerning the "misuse" of X11
	  ------------------------------
          I agree to some extent.
          Using interclient communication as a general message switching
          system is probably wrong, at least with the simple model we
          implemented. (The event server comprises some 400 lines of code.
          The connection part of a widget has a length of some 600 lines.)
          The performance is hampered by at least the following factors
          known to us:

          -  XSendEvent limits the size of the message to 20 bytes. This
             forces us to pass absolutely all information through disk and
             pauses heavy constraints on disk caching aspects and network
             performance.

          -  There are no "local" events. If an application generates an
             event, it will inform the event server. The event server will
             then inform via network each widget separately. This will be
             done for each client application concerned about the event,
             even for the application which generated the event. This is
             the price paid for separating display code from action code.

          -  We would be glad to hear about additional limitations!

          For small distributed application, the above mentioned limita-
          tions seem to be acceptable. One unique eventserver is a very
          simple way to implement small distributed systems. Furthermore,
          this architecture can be improved to maintain the advantages
          gained at the application level and taking into account the above
          mentioned system aspects:

          Why not developing one eventserver per workstation? The applica-
          tions would remain unchanged. However the local eventserver would
          make the interface between a networking protocol e.g. DecNet and
          the X monitor. We think that in the long run such an architecture
          will be used at Luxembourg Stock Exchange.

          Even better: An improved local eventserver could receive import-
          ant information via network, store it in RAM and make it avail-
          able through global sections.  Applications would be informed of
          the delivery of informations by the eventserver and would handle
          locking via interclient communication.


          Concerning DecNet
	  -----------------
          Could we get an example of code showing how DecNet and the X
          Monitor can work together? C or ADA code would fit ideally.

RE: .12

>This model offers three advantages:

It also offers one big disadvantage, namely, that it doesn't scale upwards
to handle situations the size of the target application.  In other words, it's
an elegant, but impractical, solution.

This particular application lies outside the domain for which XSendEvent was
designed.

--PSW

    I have a customer who is using his workstation for cluster management
    of his 48 node LAV cluster.  He creates a DECTERM on each node in the
    cluster with his workstation as the display server so that he can
    easily and quickly execute any DCL command on those nodes.  He says
    that he prefers using this over using SYSMAN.  He is, however, limited
    to 32 nodes for which he can simultaneously connect.  He realizes that
    there is going to be some limit no matter what but he asked me to put
    his vote in for a 64 connection limit for the server.
    
    						Regards,
    						-Tom

Thanks for the input!  This helps me understand what our customer's
requirements are in this area.