Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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