<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.1">
</HEAD>
<BODY>
Thanks for that explanation David. Makes sense! <BR>
<BR>
On Wed, 2010-02-10 at 16:01 -0500, David Bolen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Darren Govoni &lt;<A HREF="mailto:darren@ontrenet.com">darren@ontrenet.com</A>&gt; writes:

&gt;&gt;From what I learned in other posts, the dataReceived(self, data): in the
&gt; Echo server
&gt; will get called with out-of-order data/bytes from the client. Of course,
&gt; I could be misinformed,
&gt; but what I understood before was that in this type of Protocol, I would
&gt; have to re-order
&gt; and re-assemble the bytes.  And I'm trying to avoid that, since of
&gt; course, TCP already does it.

Data being received out of order can't happen, as long as the Protocol
is layered on top of TCP, since as you say, TCP already provides that
guarantee.  The dataReceived() method is really just how the data
being received from TCP is handed to the Protocol object.

UDP can be out of order, as it provides very few guarantees above and
beyond IP itself.  But I'm not sure you can layer an IProtocol over
UDP with Twisted.

There is a general issue where you may receive the data in differently
sized chunks in dataReceived() than it might have been transmitted
originally, which is a common source of confusion to people new to
stream protocols, so perhaps you were thinking of that issue?

The stream nature (and possibility for early disconnect from the
client) is why having some internal length information for bulk
transfers is sensible.  For your original question, I was going to
suggest an older posting of mine for a similar situation where I needed
a bulk upload to augment a PB-based server, but it appears that you've
located it in the archives yourself.

&gt; But like I said, I could have been misinformed because it seems pretty
&gt; basic to write 1,2,3
&gt; to a server and have it received 1,2,3, guaranteed.

Yes - TCP guarantees that what you transmit at one end will be
received in order at the other end or not at all (e.g., outages,
disconnects, etc...).  It has a weaker guarantee in terms of no
corruption, but one that is, in combination with typical link layer
protections, generally more than sufficient for the vast majority of
connections using it each day.

-- David


_______________________________________________
Twisted-Python mailing list
<A HREF="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</A>
<A HREF="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>