[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: How to move large data inside a protocol over tcp using Qt/KDE?
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2008-09-19 3:51:38
Message-ID: gav7ka$ajf$1 () ger ! gmane ! org
[Download RAW message or body]

Friedrich W. H. Kossebau wrote:
> I want to move large data structures over the internet, as part of a custom 
> protocol over TCP. Being a newbie on asynchronous i/o over a volatile 
> connection I am also a little bit lost how to use Qt/KDE for this. 
> [snip]
> Using QAbstractSocket::bytesAvailable() does not seem too helpful. Or is there 
> a way to ask QDataStream how large the stream will be, so I can pass this in 
> front of the next stream/message? Besides, some streams will be very large, 
> and it might not be a good idea to fill the buffer with the complete data, 
> or?

Without looking at Qt's network stuff, here's a brief primer on how TCP 
networking usually works:

Given a non-blocking socket, you generally poll() it until it tells you 
you've got an event. You then read() a buffer's worth of data (a buffer 
can be whatever size you want) until you get less than the buffer size 
returned. This in a nutshell is how reading from a socket works; you ask 
for e.g. 1024 bytes. If there are 1536 bytes available, you'll get 1024 
the first time, so you read again and get 512. This is how you know 
there is no more data available at the moment. Then you go back to 
poll()ing the socket until something happens (more data or the 
connection is lost).

Probably Qt polls the socket for you as part of the event loop, hence 
the readyRead signal. Assuming Qt supports non-blocking sockets (which 
it *really* should), you just keep trying to read until you get less 
bytes back than you asked for. Normally you take the little buffers and 
use them to progressively fill a larger buffer until you have an entire 
"message". At that point, you deal with the message, do a memmove to 
shift the buffer contents back to the beginning, and repeat until you 
have reason to stop.

Hopefully something in the above makes sense :-) and perhaps will cause 
the examples to make more sense.

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]