I will better repeat, that I am no port guru, but maybe I just understand something wrongly?:
Maarten Koopmans wrote: > Hi Gabriele, > > This is a common misunderstanding that I'll put in the FAQ. > > Polling is done on the client side! It merely checks if all data has arrived > on the client! .. and that is imo what Gariele means - what does "polling" mean? Set-up of connection, sending data, closing the connection? It causes some tcp overhead imo, as establishing/closing connections each time means more packets on network ... > > What Rugby does: > > - You open a deferred request and get a ticket number. This is a non-blocking > , not-buffered port > - Whenever you 'poll' using result-ready? the client reads whatever data is > available, and checks if the message is complete. > > If the message is complete, result-available returns false, otherwise true > and you get the result by calling get-result. Put this in an event queue, do > the ordering of the messages correct and you have Gorimnb ;-) > So, you close and establish connection three times. Wouldn't it be possible to keep first connection opened whole the time, and just perform inserts/reads on the port? Thanks, -pekr- > NOTE: you are programming asynchronously which is, well, different. Ask > Graham ;-) > > You can write your own Rugby client that integrates this with a wait on the > fastcgi ports, assembles the data, checks to see if it is complete and > updates the wait list accordingly. > > HTH, > > Maarten > > Maarten Koopmans wrote: > > > Now you return listening on the fastcgi port and periodically check if > > > the result has already arrived. > > > > Do you need polling the rugby server? Would it be possible to just > > wait on the tcp port? > > > > Just being curious, > > Gabriele. > -- > 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.
