Hi, On Tuesday 11 September 2012 06:40:23 d3fault wrote: > >From this thread I've learned: It's useless for an application layer > > to receive transport layer acks... but from that we can now conclude > that the transport ack is mostly* worthless in any case where the > application layer protocol takes care of ack'ing. Might as well use > UDP. > > * = clean connect/disconnect + packet re-ordering aside -- see below
You are still mixing up concepts, just because they have the same name on
different ISO layers.
TCP ACK is *exactly* for packet reordering and retransmission control. Full
stop.
An application layer ACK has a very different purpose: it signals to the
communication partner that a message has been taken care of in the application
layer!
> Thiago, you said getting the TCP ack is redundant... but the TCP ack
> itself is redundant if you have an application layer protocol taking
> care of ack'ing too.
It is not redundant, it is useless to the application layer. There is a subtle
difference.
TCP ACK is absolutely necessary to make the guarantees that TCP makes: to
provide you with a stream (automatic retransmit, correct order). As others
have explained it is useless to the application because it does not tell you
anything about the state of processing the message.
> So the only thing really gained from TCP [when using app-layer ack'ing
> scheme] is the clean connects/disconnects and packet ordering. The
> connect/disconnect ability is easily solved with 2 new protocol
> messages, and the ordering being an important guarantee is specific to
> the application itself. Some might require it, some not.
Message ordering is independent from byte ordering in the stream. There are
plenty of other reasons to use TCP instead of UDP:
* you need a message size of >1280 bytes (or >512bytes in older serial lines)
* you don't want to spend 2 months of a highly expensive expert just on timing
analysis and other minutiae of low-level transfers
* you want to associate a session with the stream of messages
* etc.
> I think a generic application layer ack'ing scheme/class based on
> QAbstractSocket would be a great addition to Qt. So when you receive
> an ACK you are guaranteed that your receiver's application layer has
> read it in (acting upon it is something else entirely). It could also
> (optionally, to be disabled when used with TCP -- or if your specific
> use case doesn't require it) do message re-ordering for you. The class
> would also take care of re-transmitting, of course (enabled by default
> (even when ordering doesn't matter), disable-able for voip/streaming
> video scenarios (you might think in this case it'd be better to just
> use UDP... but knowing that the receiver got most of the messages is
> still valuable information... whereas with UDP you just cross your
> fingers and assume they did)).
>
> ^^I'll try to keep this in mind as I implement my application layer
> ack'ing scheme... but obviously my own specific use case takes
> priority sorry :-P.
Why re-implement TCP when it already exists? Because that is all that you can
do: a transport layer implementation. You cannot know the specific
requirements of other peoples' protocols.
A simple ACK is not enough - normally more logic is needed (response codes,
response payloads, application level message handling, etc.).
> To end, are there any plans to make QSslSocket work with QUdpSocket?
> The overheads of TCP are redundant.
As far as I know there are none: SSL is primarily a stream protocol - you
either heavily adapt it to the peculiarities of UDP or you re-implement the
TCP retransmit and reorder logic with different timings.
> inb4 a handful of people miss the point and try to explain to me why
> tcp ack's are not redundant. "you're guaranteed ordering" hurrrrr
Please remind me to never use one of your protocols until you've properly
educated yourself on the use of layered protocols. Start with a good book
about the ISO reference model (e.g. Tanenbaum comes to mind).
Konrad
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
