<br><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 3:33 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="it">On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Fri, Jun 26, 2009 at 2:11 PM, James Robinson <span dir="ltr"><<a href="mailto:jamesr@google.com" target="_blank">jamesr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div><div class="gmail_quote"><br></div></div></div>
<div><br></div><div>Forcing applications to build their own send/ack functionality would be pretty tragic considering that WebSockets are built on top of TCP.</div><div><br></div><font color="#888888"><div>- James</div></font></blockquote>
<div><br></div></div><div>Every time I've written a response/reply protocol on TCP I've needed to put in my own acks - how else do you know your message has been delivered to the remote app layer? </div><div></div>
</div></blockquote><div><br></div></div><div>Classic networking problem... if you do send the ack... how does the ack sender know the other side has received it... and so on.</div></div></blockquote><div><br></div></div>
<div>Precisely, and complicated by the fact that the app layers I've worked with don't actually expose TCP acks to the app, so you can't even tell that the remote side has acked your packets.</div><div class="it">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><br></div><div>
One could argue that WebSockets should do this for you, but I like leaving this up to the app as it gives them more flexibility.</div><div></div></div></blockquote><div><br></div></div><div>Yes.</div><div><br></div><div>
But knowing if the data your queuing to be sent is backing up in your local system instead of being pushed out is different than knowing if the remote side has received it and processed it. The former can be done w/o changing the websocket network protocol, the latter cannot.</div>
</div></blockquote><div><br></div></div><div>Is the "queued up data is backing up" problem any different from somebody doing a ton of async XHR requests, some of which may need to be queued before being sent?</div>
</div></blockquote><div><br></div><div>No. But the difference is each XHR tells you when its been sent and gives you the response when its received. With this info, apps can rate limit things. WebSocket.postMessage doesn't tell you when that message has been sent.</div>
<div><br></div><div>Suppose your sending 'i'm alive' messages. If the message you sent 5 minutes ago hasn't really been sent, you wouldn't want to queue another 'i'm alive'.</div><div><br></div>
<div>If you're uploading a large data set incrementally across many distinct postMessage calls (perhaps to leave room for other control messages interspersed amoungst them, or to present progress info), how do you know when to queue more data to be sent.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div><div>
</div></div>
</blockquote></div><br>