KExtendedSocket oddities

[Malte Starostik]

On Friday 13 December 2002 23:47, Thiago Macieira wrote:
> Malte Starostik wrote:
> >Somehow I've always had bad luck with sockets in KDE/Qt. QSocket either
> > did too many unexpected things or wasn't lowlevel enough for what I
> > wanted. KSocket was always better but still something was missing. So now
> > I tried KExtendedSocket and failed again, partially. Maybe I have too
> > weird requirements *g*
> >I'll think a bit more about what the exact problems were and see how I'll
> > get along this time; for the TCP part it looks very promising.
>
> I'd like to know what your requirements are. I've designed KExtendedSocket
> having in mind all possible uses, which turned out to be a backfire: the
> class got too big. The normal socket uses in kdelibs and kdebase, which I
> converted to KExtendedSocket, were taken into account, but seldom have I
> received reports for more complex situations. Yours is one of the first.

I'm writing a program that does both UDP and TCP communications - don't want 
to tell too much right now...
I'm using KExtendedSocket for the latter now, but for the former I can't. The 
sendto/recvfrom thing I mentioned earlier isn't that bad as I could always 
access the socket fd for this. The main problem is that KES creates a socket 
only on connect() or listen(), both of which I cannot use in this case. The 
UDP socket should just be created and bound to a given address. Then, packets 
are to be received from and send to many different hosts.

> Before the release in KDE 2.2, the need for buffered sockets arose (so as
> to mimic QSocket's behaviour) and then the class got more complicated than
> I had intended it to. The initial idea was to have a separate
> KBufferedSocket, wrapping around a KExtendedSocket and a KBufferedIO
> (problem: both inherit QObject and emit signals). KExtendedSocket was
> intended be a low-level I/O only -- something like a KSocketDevice that I
> proposed in the last e-mail.

One thing that came to my mind, but I'm not sure if it's really generally 
useful. Many protocols include a header that somehow specifies the length of 
the following data. For cases where this length is fairly small so all of the 
data can be buffered in memory, it could be helpful if the app could tell KES 
to only emit the next readyRead() signal after all of the data is available, 
kind of like an asynchronous waitForMore(), so the app will not have to check 
on every signal whether all of the data is there now.

> Anyways, something I forgot to mention in the proposal was to move the
> resolver functions to a new class, a KResolver. That could also include
> things like service names to port translation, gethostname (which has
> always been a problem), etc.

This sounds great!

-Malte
-- 
short circuit; auto accident; static electricity; struct by_lightning;
double trouble; unsigned long letter; float valve; short pants; void check;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021216/10be8488/attachment.sig>