X11R4 client<->server communication question (sockets question)

X11R4 client<->server communication question (sockets question)

Post by p.. » Thu, 01 Aug 1991 18:30:16



I have X11R4 for the xenix operating system. The communication is with
a socket-emulation package using named pipes. Everything works
allright, except for that some clients generate messages in a higher
speed than the server can process them. There must be some kind of
mechanism to stall a client making messages to the server, so that the
server has a chance to keep up.

The listen(s, backlog) library function has the backlog parameter
which appears like it is meant for prohibiting a client to generate a
too huge backlog of messages, but the listen(2) manpage says:
" The backlog parameter    defines the maximum length the queue
  of pending connections may grow to.", it does not say anything about
how long the queue of messages can be for an already established
connection.

So the question is what mechanism is limiting the number of uprocessed
messages that can be sent to a server from a client. What is limiting
the number of outstanding packets that can be sent over a socket
connection without stalling the sender (if this is what keeps x
clients like ico in check)

--
-- Per Lindqvist


 
 
 

X11R4 client<->server communication question (sockets question)

Post by Stuart Kreitm » Sun, 04 Aug 1991 01:14:13


        To paraphrase your posting:
                What is flow control?
|>
|> The listen(s, backlog) library function has the backlog parameter
|> which appears like it is meant for prohibiting a client to generate a
|> too huge backlog of messages, but the listen(2) manpage says:
        listen(2) is used by the X server to listen for incoming connection
        attempts, which it will then accept(2). In a true socket environment,
        accept() returns a new socket which is a handle on a completed circuit.
        Xlib doesn't use listen() at all, and it is not related to flow control.
|> " The backlog parameter      defines the maximum length the queue
|>   of pending connections may grow to.", it does not say anything about
|> how long the queue of messages can be for an already established
|> connection.
        This is for a server to allow incoming connection attempts to
        backup waiting for acceptance.
|>
|> So the question is what mechanism is limiting the number of uprocessed
|> messages that can be sent to a server from a client. What is limiting
|> the number of outstanding packets that can be sent over a socket
|> connection without stalling the sender (if this is what keeps x
|> clients like ico in check)
        The sender should eventually stall.  X requests are buffered in Xlib
        and eventually flushed out to the server. If the pipe or socket is
        full, the write() will return error (it was conditioned non-blocking)
        Eventually, the Xlib buffer of requests will stall or fill up and stall.
        I am skipping the detail of how the comm resumes after the server
        eats some of the requests.

        Your question seems to lead to: how are unix pipes used to emulate
        sockets? UNIX pipes are a problematic choice for local domain X
        transport. They are slow, expensive, and buffer very little (usually
        2k->4k). You might get better performance locally by going through
        your ethernet subsystem.  On most implementations,
        :0.0 or unix:0.0 chooses the local domain setup, while
        <yournodename>:0.0 chooses the net.

        rsvp how this works for you.
skk

 
 
 

X11R4 client<->server communication question (sockets question)

Post by p.. » Mon, 05 Aug 1991 15:07:00



>    Your question seems to lead to: how are unix pipes used to emulate
>    sockets? UNIX pipes are a problematic choice for local domain X
>    transport. They are slow, expensive, and buffer very little (usually
>    2k->4k). You might get better performance locally by going through
>    your ethernet subsystem.  On most implementations,
>    :0.0 or unix:0.0 chooses the local domain setup, while
>    <yournodename>:0.0 chooses the net.

If I use named pipes it is because I don't have an ethernet subsystem.
My problem is that the pipes buffer too much!
There was a discussion of the speed of different transport methods, on
the net, a while ago, and the answer was: It does not matter, since the
major bottleneck on unix systems are the context switches.

I start ico, or something, and the problem is that the backlog of
mouse events becomes so big, that I hardly can stop the client. (The
mouse does not react immediately, and when I click the mouse, it takes
a very long time before something reacts. Meanwhile the demo is
running nicely) Maybe there is another problem - that the mouse events
are not put on higher priority than the client messages. Or maybe that
the server nice should be higher than the client nice.
--
-- Per Lindqvist


 
 
 

1. file transfer question: sun<=>telnet<=>terminal server<=>modem ?

I can get to a modem from my sun at work by:

------------------------------
% telnet pnet

connected to pnet

Enter system name: DIAL

(2400bps full duplex)
ATDT9737-3249

gdx-login: jay
password:

(stuff deleted)

gdx%

------------------------------

OK, now that I'm connected, I want to download a file from the remote host.
What can I do?

_______________________________________________________________________________

This is your Brain: (unix)              GDX-BBS (717) 737-3249 Trailblazer Plus
This is your Brain on drugs: (MSDOS)     Unix and MSDOS File areas + Xenix bins

2. Netscape History

3. <><><> MOUNTING EXTENDED PARTITION <><><>

4. Help with harddrives!

5. Wanted: <><><> Unix Specialist <><><>

6. Convincing CIO to switch to Linux/Apache and PHP/MySQL istead of Windows/IIS and ColdFusion/MS SQL

7. LILO help <><><><><><>

8. HW Settings for Western Digital WDE9100

9. <<->> x-server and backspace: help needed please <<->>

10. >>>Connecting to ISP Questions<<<

11. >>>Sun O.S. 4.1.3 U1 Questions<<<

12. <<< AMD question >>>

13. ***>>> Summary: Questions on sending binary files by e-mail <<<***