RSocket and bluetooth: send problem - Symbian

"Vigen Issahhanjan" <vigen.issahhanjan@fieldforce.com> writes:

> And RunL function is being called before the data was physically
> sent - this is not good at all!!!

Getting to RunL only signifies that the kernel has accepted your
buffer content, and your application is free to reuse the buffers for
new data. (After Send, and before RunL gets called, your application
must not modify the buffers or descriptors -- if it does, what goes
out, can be either the modified data or not, depending on how the
processes execute).

It has NEVER meant that the data has been physically sent out. It
still may be in the drivers buffers.

Additionally, for datagram sockets, if drivers buffers are full,
kernel may just drop the packets. For stream sockets, the writes may
block, but I don't know BT enough to comment whether there is a
problem with blocking on full buffers or not.

(For TCP/IP it works that way: UDP datagrams are just dropped if you
send too much too fast, TCP streams block).

This is getting even stranger! Ok, let it be the way you told, Markku. One=
=20
addition to my post then is that I use the stream socket. And then more=20
questions arise:

1. The RSocket's Send method does not block at all! It always exits the=20
call, and there's no return value for this function: void Send(...).

2. There's no RunL call with some error in iStatus when the bluetooth is=20
stuck.

3. After bluetooth is stuck, I disconnect from the other party. What happen=
s=20
is the phone's RunL method is called with KErrDisconnect in iStatus, so=20
bluetooth does actually work, but... If I try sending something after BT is=
=20
stuck - application hangs and nothing happens on the other party of the=20
connection.

So, one bug question is: where should I get the information, that the socke=
t=20
is physically ready to send some data? Any programmer tries to send as fast=
=20
as he can, so how should I know if I reached the speed limit?

Thank you.

Vigen

"Markku Savela" <msa@burp.tkv.asdf.org> wrote in message=20
news:87r7ljr9jt.fsf@burp.tkv.asdf.org...
> "Vigen Issahhanjan" <vigen.issahhanjan@fieldforce.com> writes:
>
>> And RunL function is being called before the data was physically
>> sent - this is not good at all!!!
>
> Getting to RunL only signifies that the kernel has accepted your
> buffer content, and your application is free to reuse the buffers for
> new data. (After Send, and before RunL gets called, your application
> must not modify the buffers or descriptors -- if it does, what goes
> out, can be either the modified data or not, depending on how the
> processes execute).
>
> It has NEVER meant that the data has been physically sent out. It
> still may be in the drivers buffers.
>
> Additionally, for datagram sockets, if drivers buffers are full,
> kernel may just drop the packets. For stream sockets, the writes may
> block, but I don't know BT enough to comment whether there is a
> problem with blocking on full buffers or not.
>
> (For TCP/IP it works that way: UDP datagrams are just dropped if you
> send too much too fast, TCP streams block).=20

"Vigen Issahhanjan" <vigen.issahhanjan@fieldforce.com> writes:

> 1. The RSocket's Send method does not block at all! It always exits the=
=20
> call, and there's no return value for this function: void Send(...).

Yes, send just queues the request to kernel and returns. If you are
using AO's, then the active scheduler will call the RunL when the
kernel has processed the request and changed the iStatus to something
else than pending. (Or, one could use User::WaitForRequest, if not
using AO's).

You CANNOT do a new write to same socket until RunL is called (or
iStatus has become ready).

> 2. There's no RunL call with some error in iStatus when the bluetooth is=
=20
> stuck.

As said, I don't have experience on BT sockets. Assuming they work
correctly, stream socket write should block until there is room in
buffers again. Then, RunL should be happening.

> If I try sending something after BT is stuck - application hangs and
> nothing happens on the other party of the connection.

As said above, you cannot write until previous write has indicated
completion on RunL. So trying to write before socket is ready for it,
is doomed to fail anyway (actually, you should get a panic on it...)

> So, one bug question is: where should I get the information, that the soc=
ket=20
> is physically ready to send some data? Any programmer tries to send as fa=
st=20
> as he can, so how should I know if I reached the speed limit?

For correctly working stream sockets, if you only activate new writes
from RunL as long as you have data to send, you should get it going as
fast as it can. RunL gets called when system is ready to accept more
(initially these should happen fast as buffers fill).

Markku, I do exactly as you've said! And that was just my question: whaen i=
=20
do sends very fast they stuck. Stuck meaning the other party DOES NOT=20
recieve anything!

Vigen

"Markku Savela" <msa@burp.tkv.asdf.org> wrote in message=20
news:87k6rb3bse.fsf@burp.tkv.asdf.org...
> "Vigen Issahhanjan" <vigen.issahhanjan@fieldforce.com> writes:
>
>> 1. The RSocket's Send method does not block at all! It always exits the
>> call, and there's no return value for this function: void Send(...).
>
> Yes, send just queues the request to kernel and returns. If you are
> using AO's, then the active scheduler will call the RunL when the
> kernel has processed the request and changed the iStatus to something
> else than pending. (Or, one could use User::WaitForRequest, if not
> using AO's).
>
> You CANNOT do a new write to same socket until RunL is called (or
> iStatus has become ready).
>
>> 2. There's no RunL call with some error in iStatus when the bluetooth is
>> stuck.
>
> As said, I don't have experience on BT sockets. Assuming they work
> correctly, stream socket write should block until there is room in
> buffers again. Then, RunL should be happening.
>
>> If I try sending something after BT is stuck - application hangs and
>> nothing happens on the other party of the connection.
>
> As said above, you cannot write until previous write has indicated
> completion on RunL. So trying to write before socket is ready for it,
> is doomed to fail anyway (actually, you should get a panic on it...)
>
>> So, one bug question is: where should I get the information, that the=20
>> socket
>> is physically ready to send some data? Any programmer tries to send as=
=20
>> fast
>> as he can, so how should I know if I reached the speed limit?
>
> For correctly working stream sockets, if you only activate new writes
> from RunL as long as you have data to send, you should get it going as
> fast as it can. RunL gets called when system is ready to accept more
> (initially these should happen fast as buffers fill).
>=20

"Vigen Issahhanjan" <vigen.issahhanjan@fieldforce.com> writes:

> Markku, I do exactly as you've said! And that was just my question: whaen=
i=20
> do sends very fast they stuck. Stuck meaning the other party DOES NOT=20
> recieve anything!

Ahh, then this goes beyond my knowledge.

Which phone are you running this on?

Have you tried on another phone?

Perhaps there is an issue with the devices bluetooth stack?

David

Vigen Issahhanjan wrote:
> Hello,
>=20
> I use the following function for sending data over Bluetooth:
> void Send(const TDesC8& aDesc,TUint someFlags,TRequestStatus&
> aStatus,TSockXfrLength& aLen);
>=20
> It works just fine: aLen always have the sent length (but you should not
> delete the aDesc until the RunL is called), except the situations when I =
try
> sending 100 times 10 kB buffers very fast. Then on some point the Bluetoo=
th
> is simply stuck - no event comes that the data is sent. And on recieving
> side one can see, that data was sent only partially. And nothing happens.
> Interesting is that when I disconnect from the recieving side, phone does
> recieve the Disconnect event! :-| This is a complete mistery now: when I =
put
> a 100 ms timeout with User::After(100), then I can send this data - but t=
his
> is not a good solution.
>=20
> What I think is there buffer overflow appears in bluetooth controller on =
the
> phone. And bluetooth transmitter stops workin, or something like that. An=
d
> RunL function is being called before the data was physically sent - this =
is
> not good at all!!!
>=20
> So, how can I avoid this kind of behaviour? Are there any HCI or some
> low-level protocol commands to verify is transmitting buffer empty or not=
?
>=20
> Thank you in advance,
> Vigen
>=20
>=20
>=20

Markku Savela wrote:
> "Vigen Issahhanjan" <vigen.issahhanjan@fieldforce.com> writes:
>=20
>=20
>>Markku, I do exactly as you've said! And that was just my question: whaen=
i=20
>>do sends very fast they stuck. Stuck meaning the other party DOES NOT=20
>>recieve anything!
>=20
>=20
> Ahh, then this goes beyond my knowledge.

Maybe the buffer used to send is too small.
Try to use the method SetOpt on your writing socket (Option KSOSendBuf).

--=20
Regards,
Tibo