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 ... 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 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? > 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 ... -pekr- > Under NT 4 I managed to eat up all CPU if I didn't read alkl bytes on a > server before closing a port. This is fixed in 4.3 > > My (wild) guess: Rebol puts a small wrapper on TCP/IP stacks in different > OS'es with more and more advanced features, such as non-blocking I/O. As some > platforms/kernels have (different) bugs you see this in Rebol scripts.... > > --Maarten > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
