[REBOL] Re: Rugby / TCP woes
From: koopmans:itr:ing:nl at: 27-Nov-2001 15:17
Hey,
See below....
> Maarten Koopmans wrote:
> > Hi all,
> >
> > I have had some discussions about adding persistent connections to Rugby.
> > It may be good to know that I tested this feature for 4.3 but that on an
> > Ethernet the setup time for /no-wait/direct TCP ports is so short that
> > reusing connections is actually fourt times slower. I have no clue why!
>
> 1) Yes, it should not be slower in any way imo! TCP connection is no magic
> - just raw packets on network. In reality, it should be just reverse - to
> set-up TCP connection, machine requesting connection sends SYN packet,
> remote machine sends SYN, ACK packet, acknowledging connection acceptance,
> then first machine once again confirms by ACK packet - so, actually
> setting-up tcp connection is three way process, while sending packet
> containing data means sending PSH, ACK with data, while other side is
> confirming with ACK, or PUSH, ACK, if sending data too ... or something
> like that ...
>
Exactly. Although behaviour may differ on the internet. It *is* strange. But
you see that I have currently no reason to do persistent connections in Rugby.
> 2) as for keeping connection "alive". I thought you are doing so with
> /deffered type of Rugby connection, no? The only one "problem" is - you
> close the port after you get-result ticket. Another problem is, that you
> have to explicitly poll server each n secs, if the result is already
> available. If I understand it correctly, you use http tunneling. Althought
> I don't fully understand what is going on with http tunneling, isn't it
> really possible to re-use already opened channel for transfer from server
> side, to client side? Scenario:
>
> - connection to Rugby server
> - server stores port in a block of port
> - client stores port in a block of port
>
Yes.
> Is that right so far? And now - what is the problem for e.g. for chat
> server, to redistribute (insert-to-port) messages to each client port
> registered, instead of letting clients to poll the server? And btw- what
> does polling mean here? Is server contacted with new connection? As becuase
> I just looked at
> 'http-result-available? function, and it seems to me, that you only do
> 'copy on port, or is there really reconnection happening to the server?
>
Yes. result-available? reads data from the client port (the *client* TCP
stack) and does *not* poll the server. If it sees that it has all the data
(=the return data) it closes the underlying port once you read it in the
application.
So: all requests use the same port for request/return. In fact,
wait-for-result is just:
until [result-available? index get-result index]
Then the mysterious httpr (r for rugby) is just a copy of RT's http protocol
that does not wait for the first two lines of the return header. Truely
non-blocking. Drawback: you loose automatic http redirects and such. You get
the complete http response back, so you can implement that yourself.
> > SOme other news: Rebol seems to be inconsistent in its network behaviour.
> > I tested on Linux 2.4.x libc6, but Petr runs on 2.2.16 and observes CPU
> > eating. Shouldn't the same script run the same on all platforms?
>
> What is more, there seems to be one strange thing happening. On czech
> version of W95, W98, on various set-ups, ranging from P300 to P650, the
> result of rugby communication is always the same - 40 - 44 sec for loop of
> 100 'echos. W2Kcz are OK. I am really curious, what is slowing the
> communication down down ...
>
Yes... platform dependant behaviour. Don't get it either.
--Maarten