Hi, i need some hints.
I writed a RFCOMM cleint side socket and its servere
side. The server sends an arbitrary sequence of 2048
bytes throught the write function. The client side
read as far as it receive a 0 or -1 frem the read.
The code is like this:
char *buffer[2048];
do {
tmpPtr += nread;
nread = recv(fd, buffer, length, 0);
} while (nread > 0);
The problem arise when the server correctly send its
last bucket, the client must read it (read 2048
bytes), at the next read the client must get an EOF
(0) value from the recv...but this not happen it
receive -1 and errno=ECONNRESET. The same code works
as expected using TCP streams, but when it is used
over RFCOMM SOCK_STREAM it causes this anomaly.
Somebody could explain what happens, why the recv call
doesn't return a 0 when last data are reached on the
stream, but give an error message?
Thank's a lot
Best regards
Andrea S.
___________________________________
Nuovo Yahoo! Messenger: E' molto pi? divertente: Audibles, Avatar, Webcam, Giochi, Rubrica? Scaricalo ora!
http://it.messenger.yahoo.it
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
--- Marcel Holtmann <[email protected]> ha scritto:
> Hi Andrea,
...
> the line "addr.rc_channel = htobs(10);" is wrong,
> because rc_channel is
> only a uint8_t and so you don't need any byte
> swapping magic. Remove the
> call to htobs() and simply set the channel number.
>
> On the server side you forgot to init clientAddrLen
> before you called
> accept(). Do a "clientAddrLen = sizeof(clientAddr);"
> first.
Thanks for the hint i haven't looked at this
particular..i didn't know.
>
> for me this looks ok, because you close the
> connection from the server
> side and recv returns with an error. Does it makes
> any difference when
> you use read/write instead of recv/send?
Yes also using read/write i get the same behaviour
> For this behaviour you must send me a kernel patch
> that implements this,
> but I will only accept it if you change the L2CAP in
> the same way.
For the moment i think i'm not a kernel hacker :-(
> Regards
>
> Marcel
Thanks Marcel for the time spent
Best regards
Andrea S.
___________________________________
Nuovo Yahoo! Messenger: E' molto pi? divertente: Audibles, Avatar, Webcam, Giochi, Rubrica? Scaricalo ora!
http://it.messenger.yahoo.it
Hi Andrea,
> Thanks Marcel i attach the server and client source
> code.
> brief man:
> clientTestRC <btadddr>
> serverTestRC
>
> The code is structured to use also TCP socket, it is
> only necessary to decomment an undef and recompile.
> In tcp all work correctly...last read retrn a 0.
the line "addr.rc_channel = htobs(10);" is wrong, because rc_channel is
only a uint8_t and so you don't need any byte swapping magic. Remove the
call to htobs() and simply set the channel number.
On the server side you forgot to init clientAddrLen before you called
accept(). Do a "clientAddrLen = sizeof(clientAddr);" first.
> Out snapshot server:
> [andrea@ZANDEGIA andrea]$ ./serverTestRC
> Binding...
> Bounded on channel 10
> Listenning...
> accept ok
> loop 0
> loop 1
> loop 2
> loop 3
> loop 4
> [andrea@ZANDEGIA andrea]$
>
> Out snapshot client:
> [andrea@tsunami Bluetoooth]$ ./clientTestRC
> 00:10:C6:4D:38:AC
> bluetooth_initclient_socket called
> connecting...
> Connection opened
> Receiving ...
> nread value 1019
> nread value 1029
> nread value 1019
> nread value 1029
> nread value 1019
> nread value 1029
> nread value 2038
> nread value 10
> nread value 2048
> nread value -1
> [andrea@tsunami Bluetoooth]$
for me this looks ok, because you close the connection from the server
side and recv returns with an error. Does it makes any difference when
you use read/write instead of recv/send?
I seems that you really wanna the behaviour described in the recv manual
page:
RETURN VALUE
These calls return the number of bytes received, or -1 if an
error occurred. The return value will be 0 when the peer has
performed an orderly shutdown.
For this behaviour you must send me a kernel patch that implements this,
but I will only accept it if you change the L2CAP in the same way.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
>
> are you sure that your client/server code is
> correct, because until you
> don't close the socket on the server side, the
> client can't receive any
> additional information. It simply blocks. Show us
> the full code for both
> sides.
>
> Regards
Thanks Marcel i attach the server and client source
code.
brief man:
clientTestRC <btadddr>
serverTestRC
The code is structured to use also TCP socket, it is
only necessary to decomment an undef and recompile.
In tcp all work correctly...last read retrn a 0.
Out snapshot server:
[andrea@ZANDEGIA andrea]$ ./serverTestRC
Binding...
Bounded on channel 10
Listenning...
accept ok
loop 0
loop 1
loop 2
loop 3
loop 4
[andrea@ZANDEGIA andrea]$
Out snapshot client:
[andrea@tsunami Bluetoooth]$ ./clientTestRC
00:10:C6:4D:38:AC
bluetooth_initclient_socket called
connecting...
Connection opened
Receiving ...
nread value 1019
nread value 1029
nread value 1019
nread value 1029
nread value 1019
nread value 1029
nread value 2038
nread value 10
nread value 2048
nread value -1
[andrea@tsunami Bluetoooth]$
Best regards
Andrea S.
___________________________________
Nuovo Yahoo! Messenger: E' molto pi? divertente: Audibles, Avatar, Webcam, Giochi, Rubrica? Scaricalo ora!
http://it.messenger.yahoo.it
Hi,
I have a pretty good documented/commented application that does RFCOMM
client-server communication (client and server implemented in the applica=
tion).
Maybe you should just take a look at my code (it is really not just hacke=
d
stuff!). There is one file with all the RFCOMM stuff in.
http://mulliner.org/bluetooth/btchat/ (you want: btchatd)
... Collin
Quoting Marcel Holtmann <[email protected]>:
> Hi Andrea,
>
> > I writed a RFCOMM cleint side socket and its servere
> > side. The server sends an arbitrary sequence of 2048
> > bytes throught the write function. The client side
> > read as far as it receive a 0 or -1 frem the read.
> > The code is like this:
> > char *buffer[2048];
> > do {
> > tmpPtr +=3D nread;
> > nread =3D recv(fd, buffer, length, 0);
> > } while (nread > 0);
> >
> > The problem arise when the server correctly send its
> > last bucket, the client must read it (read 2048
> > bytes), at the next read the client must get an EOF
> > (0) value from the recv...but this not happen it
> > receive -1 and errno=3DECONNRESET. The same code works
> > as expected using TCP streams, but when it is used
> > over RFCOMM SOCK_STREAM it causes this anomaly.
> >
> > Somebody could explain what happens, why the recv call
> > doesn't return a 0 when last data are reached on the
> > stream, but give an error message?
>
> are you sure that your client/server code is correct, because until you
> don't close the socket on the server side, the client can't receive any
> additional information. It simply blocks. Show us the full code for bot=
h
> sides.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJourna=
l
> Use IT products in your business? Tell us what you think of them. Give =
us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out =
more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Andrea,
> I writed a RFCOMM cleint side socket and its servere
> side. The server sends an arbitrary sequence of 2048
> bytes throught the write function. The client side
> read as far as it receive a 0 or -1 frem the read.
> The code is like this:
> char *buffer[2048];
> do {
> tmpPtr += nread;
> nread = recv(fd, buffer, length, 0);
> } while (nread > 0);
>
> The problem arise when the server correctly send its
> last bucket, the client must read it (read 2048
> bytes), at the next read the client must get an EOF
> (0) value from the recv...but this not happen it
> receive -1 and errno=ECONNRESET. The same code works
> as expected using TCP streams, but when it is used
> over RFCOMM SOCK_STREAM it causes this anomaly.
>
> Somebody could explain what happens, why the recv call
> doesn't return a 0 when last data are reached on the
> stream, but give an error message?
are you sure that your client/server code is correct, because until you
don't close the socket on the server side, the client can't receive any
additional information. It simply blocks. Show us the full code for both
sides.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users