KExtendedSocket oddities

[Malte Starostik]

On Friday 13 December 2002 21:27, Thiago Macieira wrote:
> Malte Starostik wrote:
> >* KSocketAddress inherits QObject, defines Q_OBJECT but doesn't have any
> >  signals nor slots nor does it use any QObject functionality AFAICS. This
> >  seems unneccessarily inefficient (in my situation I need to keep some
> >  hundred addresses). Also it makes KSocketAddress noncopyable, IMHO it
> > would be nice to have a copyable, value-based class instead. Of course
> > this would totally break BC
>
> These were my first KDE classes, so I didn't know better at the time. And,
> come to think of it, I had never noticed so.
>
> >* KExtendedSocket of course inherits QObject...but: its ctors don't take a
> >  QObject* parent argument, so one cannot use QObject's nice auto-deletion
> >  feature :-(
> >  Adding overloads with such a parameter wouldn't break anything, would
> > it?
>
> Probably not a problem. Again, it's the same problem as above: my first
> classes, so I didn't know better...

No problem really, just thought maybe there was a reason I didn't see. Well, 
actually there is and a good one too.

> >* setBindXXX() doesn't work on passive sockets. This is clearly
> > documented, yet it looks unnatural to me. In most cases when you bind a
> > socket, it's a passive one. Took me a while to find out that a passive
> > socket is bound to the address set with setHost() etc. instead. IMHO they
> > should either be equivalent for passive sockets or exactly the other way
> > round as now.
>
> Suggestion noted. IMO, setBindXXX() and setXXX() should then instead do the
> same job.
>
> Maybe for KDE4 we could rename the setXXX functions to setRemoteXXX... I'm
> open for suggestions.

That sounds like a good idea. If it's setRemoteXXX and setLocalXXX there 
probably aren't any ambiguities left.

> >* setAddressReusable() does nothing when called before listen().
> >  But that means bind() is called before one gets a chance to set
> >  SO_REUSEADDR. Not sure if this is a problem, but I've always seen and
> >  used SO_REUSEADDR _before_ calling bind().
>
> Hmm... noted. Shouldn't be hard to fix it. The reason it works that way is
> quite simple: there is no socket before KExtendedSocket::listen() is
> called.

I see. Maybe setAddressReusable() could just set a flag in that case and 
listen() applies it before binding.

> >* service and host resolution works primarily on QString. The overloads
> > that take a number for the port argument use QString::number() and then
> > call the QString versions. Why is this? Isn't a simple htons() far
> > cheaper than int => QString => resolution? :-) Same for IP addresses,
> > okay here I can see this would get difficult wrt IPv6 support. Still,
> > what about overloads that take an in_addr/in6_addr and skip any host
> > resolution?
>
> Services and hosts should be considered strings, not numbers. Don't ask me
> to change that. That's exactly the reason I've called them "services", not
> ports. If you use a number, you lose all possibility of SRV-based name
> lookup in the future.

[snip more good reasons to use strings]
Makes sense. 

> >* It's possible to create datagram sockets, which is nice. But somehow
> >  KExtendedSocket lacks wrappers around sendto() and recvfrom() to
> >  actually use such a socket, getting info about a packet's source and
> > all.
>
> Yes, it does... I'll get around to adding those.

Thanks!

> Anyways, I should say that I've been planning a big rewrite in that code
> for KDE4. The idea that was proposed to me was to dump the existing KSocket
> and KServerSocket and, instead, make them be derived from QSocket and use
> the KDE functionality. That would mean adding a KSocketDevice to be derived
> from QSocketDevice. And as a part of that rewrite, it could be that
> KExtendedSocket disappears and gets instead replaced by those other classes
> -- or not. I've been meaning to post a message to ask for input on that,
> and now it seems a good time as ever.

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.

-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/20021213/1dac751f/attachment.sig>