event driven mechanism? (was) Re: Re: Rugby doco - wip

well, I am no TCP guru, but ... it doesn't answe my question imo. Let's imagine my scenario: - you have proxy support in your company - my example, we use 3128 port number. So, I have to use Rugby in http mode. Rugby uses http tunneling mechanism to get thru proxy to remote 80 port. In one of your earlier posts you stated that your machine "would listen on certain port" or something like that. But that's not possible imo, as e.g. our company doesn't allow any active connection from outside ports to internal networks, being it port 80 or different ... so - we should forget tcp listen port here. As for me, I was a little bit confused, and pushed Maarten to do something similar. I didn't liked polling for result. Then I looked at 'result-available? function and found out, there is not any additional request sent to remote Rugby machine - it just checks for data on your already opened port ... so basically - functionality is in there already ... correct me someone if I am wrong ... So, the only one problem I have with the functionality is the need to poll for result using 'result-available? function (or block by using wait-for-result function). I would prefer event driven kind of behavior. IIRC, there is some kind of 'wake field in port, which is triggered each time something happens on port. But I am not sure if such port has to be put into wait-list or not. So basically, 'result-available? could be called automatically each time new data arrives on the port. Maarten? :-) -pekr-

number.

get

certain

company

being

I'm not a TCP guru at all. But i'm sure than to wait on an rebol open port it is possible also if the port has not been open in TCP listen mode (which requires server rights). The sequence should be: -client open a connection on server port 80 and send a message without waiting -client remembers the open port -client makes some stuff and then wait on the already open port -server receive message, makes some stuff and then reply on the same connection -client awakes and read the reply message I think should work also a more complex mode: -client opens a connection on server port 80 and sends a message with an unique id -client closes the port -client remembers the unique id of message -client makes some stuff -server receives the message, closes the connection and makes some stuff -client opens a new connection on server port 80 and sendes a message with previous id -client wait for a reply -server receives the message, associates the id to the result and then replies on the same connection -server closes the connection -client reads the reply message and closes the connection --- Ciao Romano