# BUG: Problems with 1.8.0p5 and fast multiple connect requests.

Mark R. Bowyer (mbowyer@uk.cv.com)
Tue, 23 Jul 1996 06:36:13 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    Hi guys,

    here's an interesting one.  Jeni has been playing with serving web pages from
    her own personal MOO at our site.  She has found that, when she's using frames
    to get 3 pages in on one screen, she gets wierd results.  Sometimes she gets
    them all fine.  Sometimes she gets none of them, mostly 1 or 2 don't ever get
    sent.  The log file for this period of connects goes as follows.  Accepts
    obviously mean that it has allowed the connect.  A Disconnect for it then
    follows in course.  The *** error means it failed to connect and GET the text.
    We've included more of the working ones to show that the order and speed of
    requests doesn't seem to be the only factor.  jenimac is her Mac, darkhorse is
    my Sun.

    Note we are having no problems with single web pages or player connects.  It
    *may* also be related to requests in quick succession from the same client,
    therefore.

    Jul 23 13:15:33: ACCEPT: #-6679 on port 5556 from jenimac, port 1507
    Jul 23 13:15:34: ***  An event requires
    attention
    Jul 23 13:15:35: *** Accepting new network connection: An event requires
    attention
    Jul 23 13:15:35: ACCEPT: #-6680 on port 5556 from jenimac, port 1510
    Jul 23 13:15:36: DISCONNECTED: #-6679 on port 5556 from jenimac, port 1507
    Jul 23 13:15:38: DISCONNECTED: #-6680 on port 5556 from jenimac, port 1510
    Jul 23 13:15:40: ACCEPT: #-6681 on port 5556 from darkhorse.CV.COM, port 36180
    Jul 23 13:15:42: DISCONNECTED: #-6681 on port 5556 from darkhorse.CV.COM, port
    36180
    Jul 23 13:15:50: ACCEPT: #-6682 on port 5556 from darkhorse.CV.COM, port 36181
    Jul 23 13:15:51: DISCONNECTED: #-6682 on port 5556 from darkhorse.CV.COM, port
    36181
    Jul 23 13:15:53: ACCEPT: #-6683 on port 5556 from darkhorse.CV.COM, port 36182
    Jul 23 13:15:54: DISCONNECTED: #-6683 on port 5556 from darkhorse.CV.COM, port
    36182
    Jul 23 13:15:58: ACCEPT: #-6684 on port 5556 from darkhorse.CV.COM, port 36183
    Jul 23 13:15:59: DISCONNECTED: #-6684 on port 5556 from darkhorse.CV.COM, port
    36183
    Jul 23 13:16:24: ACCEPT: #-6685 on port 5556 from darkhorse.CV.COM, port 36184
    Jul 23 13:16:27: DISCONNECTED: #-6685 on port 5556 from darkhorse.CV.COM, port
    36184
    Jul 23 13:16:28: ACCEPT: #-6686 on port 5556 from darkhorse.CV.COM, port 36185
    Jul 23 13:16:28: ACCEPT: #-6687 on port 5556 from darkhorse.CV.COM, port 36186
    Jul 23 13:16:28: ACCEPT: #-6688 on port 5556 from darkhorse.CV.COM, port 36187
    Jul 23 13:16:29: DISCONNECTED: #-6687 on port 5556 from darkhorse.CV.COM, port
    36186
    Jul 23 13:16:30: DISCONNECTED: #-6686 on port 5556 from darkhorse.CV.COM, port
    36185
    Jul 23 13:16:30: DISCONNECTED: #-6688 on port 5556 from darkhorse.CV.COM, port
    36187

    Now, "Accepting new network connection:" is from net_sysv_tcp.c,
    proto_accept_connection().  It means that either t_listen() or t_accept(), both
    system calls, have returned an error.  The rest of the error we are assuming is
    from the following t_errno value:

         TLOOK               An asynchronous event  has  occurred  on
                             this  transport  endpoint  and  requires
                             immediate attention.

    though since the MOO ignores the value set here, we have no way of finding out,
    other than starting to hack the code to find it.  Since this is a timing issue,
    we believe, that may be counter-productive.

    What we *think* might be happening is shown in the paste below.  If so, I think
    the best solution would be to try the t_listen/t_accept again?

    >From the t_accept man page:

         For both types of endpoints, t_accept() will  fail  and  set
         t_errno  to  TLOOK  if there are indications (for example, a
         connect or disconnect) waiting to be received on  that  end-
         point.

    Either way, this is now somewhat over my head, and so we figured you'd want to
    see it.  Any ideas?  If we *have* traced this to the correct point, is there any
    chance of patching this so that if TLOOK is set, it retries the t_accept()?
    This is proving quite an irritation for us.

    Many thanks for reading this far down a long and boring post,

    Moredhel/TC.  MOOtiny. (spsyc.nott.ac.uk/128.243.31.4 8888)