On Monday 10 September 2012 12:02:38 Till Oliver Knoll wrote:
> Am 09.09.2012 um 21:17 schrieb Justin Karneges :
> > You're correct in that it is reliable under the hood. The problem is
> > really just that most TCP APIs don't expose to the app what has been
> > acknowledged.
>
> Not entirely true
Sorry for sending that message directly to you, Thiago — forgot to fix
the address before hitting the "Send" button. :)
Original Message
On terça-feira, 11 de setembro de 2012, às 16.33.44, you wrote:
> There's a paper
> (http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sig
When should that "application-level ACK" be sent?
When QAbstractSocket sees theres's some data available? That doesn't make
[much] sense IMHO -- nothing stops the application from throwing that data
away without any processing (due to crash or any other reason).
When the application reads the dat
Am 11.09.2012 um 14:22 schrieb d3fault :
> ...
NACK!
Good luck!
Oliver
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Op 11-9-2012 14:22, d3fault schreef:
> You haven't given any concrete reasons why I'm wrong, so I'll just
> assume you are until you prove otherwise (WHEEE). Repeating
> yourself doesn't count.
>
> Not every application protocol could use it... but a lot could.
>
> Also, responses and error
You haven't given any concrete reasons why I'm wrong, so I'll just
assume you are until you prove otherwise (WHEEE). Repeating
yourself doesn't count.
Not every application protocol could use it... but a lot could.
Also, responses and error codes are something else entirely. That
would be
2012/9/11 d3fault :
> 3rd time down the waterslide... this is so fun ^_^
>
> On Tue, Sep 11, 2012 at 1:58 AM, Till Oliver Knoll
> wrote:
>> I understood very well that you're talking about a "generic
>> Application layer ACK" concept/protocol (implemented in e.g.
>> QAbstractSocket or in some othe
3rd time down the waterslide... this is so fun ^_^
On Tue, Sep 11, 2012 at 1:58 AM, Till Oliver Knoll
wrote:
> I understood very well that you're talking about a "generic
> Application layer ACK" concept/protocol (implemented in e.g.
> QAbstractSocket or in some other Qt related class).
>
No you
2012/9/11 d3fault :
> Our thoughts seem to have diverged a few emails back. I'm no longer
> talking about TCP/Transport layer when mentioning ACKs... just the
> concept of acknowledgment. Screw it, I'm just going to go down my
> water slide repeatedly.
I understood very well that you're talking ab
Our thoughts seem to have diverged a few emails back. I'm no longer
talking about TCP/Transport layer when mentioning ACKs... just the
concept of acknowledgment. Screw it, I'm just going to go down my
water slide repeatedly.
Also, what does intermangle mean? Seems to be a made up word and I
can't
Op 11-9-2012 9:44, Till Oliver Knoll schreef:
> 2012/9/11 d3fault :
>> lol thanks for explaining to me what TCP is. Already knew that before
>> making this thread...
> There still seem to be some mis-conceptions about what TCP *really* is
> (and "network layers" in general) on your side though ;)
>
2012/9/11 d3fault :
> lol thanks for explaining to me what TCP is. Already knew that before
> making this thread...
There still seem to be some mis-conceptions about what TCP *really* is
(and "network layers" in general) on your side though ;)
Let's go through it step by step (I'm no network expe
lol thanks for explaining to me what TCP is. Already knew that before
making this thread... just didn't know the transport ACKs weren't
accessible from application layer (especially after reading that
[fixed] misleading documentation).
But how can you say:
a) TCP ACKs can't be used for application
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 protoco
On Tuesday 11 September 2012 01:48:08 Constantin Makshin wrote:
> TCP's 16-bit checksum isn't [very] reliable by today's standards, so doing
> additional integrity checks at application level is not necessarily a bad
> idea (in situations where correctness of the transmitted data is REALLY
> import
Am 11.09.2012 um 06:40 schrieb d3fault :
>> 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 ...
>
> * = clean connect/disconnect + packet re-ordering aside --
>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/di
On terça-feira, 11 de setembro de 2012 03.48.08, Constantin Makshin wrote:
> TCP's 16-bit checksum isn't [very] reliable by today's standards, so doing
Why do you say that?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel S
TCP's 16-bit checksum isn't [very] reliable by today's standards, so doing
additional integrity checks at application level is not necessarily a bad
idea (in situations where correctness of the transmitted data is REALLY
important/critical).
On Sep 10, 2012 11:43 PM, "Konrad Rosenbaum" wrote:
> *
Hi,
let's cut it short and come back to your problem.
On Sunday 09 September 2012 20:54:09 d3fault wrote:
> Haha, funny. Reliable doesn't mean reliable. Who knew...
No it is just a different kind of reliable.
TCP reliable: TCP guarantees that you have a stream. Bytes arrive at the
application
On segunda-feira, 10 de setembro de 2012 14.53.31, Till Oliver Knoll wrote:
> > If TCP is reliable by doing ACKs, why the hell would you need to track
> > ACKs
> > too?
>
> Because, since that information is around anyway, why not use it (apart from
> that it seems not accessible in real world imp
Am 10.09.2012 um 13:36 schrieb Thiago Macieira :
> On segunda-feira, 10 de setembro de 2012 13.33.24, Till Oliver Knoll wrote:
>> Am 10.09.2012 um 13:19 schrieb Thiago Macieira :
>>> ...
>>> It's a layering violation for the Application layer to depend on how the
>>> Transport layer works. As I po
On Sep 10, 2012 4:37 AM, "Thiago Macieira"
wrote:
>
> On segunda-feira, 10 de setembro de 2012 13.33.24, Till Oliver Knoll
wrote:
> > Am 10.09.2012 um 13:19 schrieb Thiago Macieira <
thiago.macie...@intel.com>:
> > > ...
> > > It's a layering violation for the Application layer to depend on how
th
On segunda-feira, 10 de setembro de 2012 13.33.24, Till Oliver Knoll wrote:
> Am 10.09.2012 um 13:19 schrieb Thiago Macieira :
> > ...
> > It's a layering violation for the Application layer to depend on how the
> > Transport layer works. As I pointed out, the Transport layer may deliver
> > the by
Am 10.09.2012 um 13:19 schrieb Thiago Macieira :
> ...
> It's a layering violation for the Application layer to depend on how the
> Transport layer works. As I pointed out, the Transport layer may deliver the
> bytes and even ACK them, but the Application layer above may never receive
> them, f
On 10 September 2012 11:19, Thiago Macieira wrote:
>
>
> There's simply no way to get the number of bytes ACK'ed from the other side. I
> did search the Linux TCP API yesterday and I couldn't find anything suitable.
> And even if there were such a way, the ACK information is useless, since the
> a
On segunda-feira, 10 de setembro de 2012 12.54.50, Till Oliver Knoll wrote:
> Then it is about time that the Qt docs be corrected:
>
> "The bytesWritten() signal is emitted when data has been written to the
> socket (i.e., when the client has read the data)."
>
> With emphasis on "the client has
Am 10.09.2012 um 12:19 schrieb Thiago Macieira :
> On segunda-feira, 10 de setembro de 2012 12.02.38, Till Oliver Knoll wrote:
>> Am 09.09.2012 um 21:17 schrieb Justin Karneges :
>>> You're correct in that it is reliable under the hood. The problem is
>>> really
>>> just that most TCP APIs don't e
On segunda-feira, 10 de setembro de 2012 12.02.38, Till Oliver Knoll wrote:
> Am 09.09.2012 um 21:17 schrieb Justin Karneges :
> > You're correct in that it is reliable under the hood. The problem is
> > really
> > just that most TCP APIs don't expose to the app what has been
> > acknowledged.
>
>
Am 09.09.2012 um 21:17 schrieb Justin Karneges :
> You're correct in that it is reliable under the hood. The problem is really
> just that most TCP APIs don't expose to the app what has been acknowledged.
Not entirely true: on a "socket level" you get the number of bytes which have
been ACK'ed
Am 09.09.2012 um 20:01 schrieb d3fault :
> ...
>
> A random guess: does bytesWritten() get triggered by a TCP ACK sent by
> the _receiver's_ internal buffer (regardless of whether my code has
> read it in or not yet (if I just ignore the readyRead()))?
Yes! There was one time when our professor
On Sep 9, 2012 12:17 PM, "Justin Karneges" wrote:
>
> You're correct in that it is reliable under the hood. The problem is
really
> just that most TCP APIs don't expose to the app what has been
acknowledged. It
> is pretty sad that everyone solves this by layering acks on top, when
acks are
> alre
You're correct in that it is reliable under the hood. The problem is really
just that most TCP APIs don't expose to the app what has been acknowledged. It
is pretty sad that everyone solves this by layering acks on top, when acks are
already being performed a layer down.
I think it would be nea
AFAIK, that numbering is done by the OS itself and is not intended to be
accessed/used by applications.
On 09/09/2012 10:54 PM, d3fault wrote:
> Haha, funny. Reliable doesn't mean reliable. Who knew...
>
> Are you sure it isn't just Qt failing to utilize the TCP protocol
> correctly? I don't mean
Haha, funny. Reliable doesn't mean reliable. Who knew...
Are you sure it isn't just Qt failing to utilize the TCP protocol
correctly? I don't mean to question your expertise, as you sound like
you know what you're talking about, but this quote from wikipedia
makes it sound like TCP does in fact do
Hi,
It is not possible to know what TCP data has been acked through QTcpSocket
alone. The bytesWritten signal is more for flow-control. Generally speaking,
TCP is designed to make it easier to send data, but TCP alone is generally not
a solution for reliable transmission. It is possible to dete
So after some more reading/testing, I'm starting to think
QIODevice::bytesWritten(qint64) might be what I'm looking for... but I
am unable to confirm it.
There's only one tiny snippet in the QAbstractSocket docs that
indicate the bytesWritten(qint64) might be a TCP ACK for that amount
of bytes: "T
TCP is a reliable protocol, but I'm wondering if Qt's abstraction
around it allows me to use it reliably. I'm using a QDataStream around
a QTcpSocket, and before I stream out I first check that
QAbstractSocket::isValid() returns true and that
QAbstractSocket::state() == ConnectedState. This all sou
38 matches
Mail list logo
