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

List:       kde-devel
Subject:    Re: [kmrml] GIFT socket code extracts + some explanations
From:       Wolfgang =?utf-8?q?M=C3=BCller?= <Wolfgang.Mueller2 () uni-bayreuth ! de>
Date:       2004-01-12 7:22:48
Message-ID: 200401120822.48020.wolfgang.mueller2 () uni-bayreuth ! de
[Download RAW message or body]

The socket blocks, it is supposed to block. However, it is not supposed to 
block forever, i.e. there *should* be something to read.

> More importantly: where is the KDE code? I see no QStrings, QValueLists
> or KExtendedSockets in your code. You said something about
> KIO::TCPSlaveBase (which is in kdelibs/kio/kio/tcpslavebase.{h,cpp}, by
> the way), 
(thanks, I was looking in kdebase...)
> but I fail to see the relation.

Oh, sorry for that. The GIFT is GIFT and not K-IFT, so there is no K-kode in 
it. KMRML is a KIO slave using the MRML protocol for accessing the GIFT. It 
sends queries to the GIFT and then waits for answers.

The code I sent you works well for PHP and PERL clients, and last time I tried 
it (that's been quite a while), it worked well for JAVA, too. 

So I would tend to see an error in kmrml. However, as far as I can see, kmrml 
just uses KSockets via the TCPSlaveBase klass. As I tend to have more 
confidence in the code made by many than in my code, I would seek the error 
in my code. This brings us to the 2 possibilities of error I see:

1. me doing something stupid in my socket code, so that I (i.e. GIFT) miss the 
moment something is sent, for example.
2. kmrml->TCPSlaveBase->KSocket doing something strange, like not flushing 
buffers, so that there is nothing to read on my (GIFT) side.

If you aren't seeing anything blatantly stupid in my code (which might make me 
lose characters or entire packets), this makes 2. more probable again.

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