Hi,
I have a small application that communicates over an L2CAP channel
(thus through a SOCK_SEQPACKET socket). The thread that does the
L2CAP communication has also some UNIX domain sockets open (AF_UNIX,
SOCK_STREAM) through which it communicates to other threads.
The trouble is that these latter sockets (UNIX domain, SOCK_STREAM) behave
like SOCK_SEQPACKET sockets, in that if I do not need read all the
available data at once, it is gone (a second call to read() blocks). As
far as I know this is not expected behavior for SOCK_STREAM sockets so I
have a couple of possible explanations:
1. Linux kernel bug
2. Bluez bug
which causes a SOCK_STREAM socket to act like a SOCK_SEQPACKET.
The system is a Fedora Core 2 with kernel 2.6.8-1.521. I have tried the
kernel 2.6.9-mh3 now and the problem still occurs.
Any ideas are greatly appreciated, thanks,
Catalin
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel
Hi Catalin,
> > > I have a small application that communicates over an L2CAP channel
> > > (thus through a SOCK_SEQPACKET socket). The thread that does the
> > > L2CAP communication has also some UNIX domain sockets open (AF_UNIX,
> > > SOCK_STREAM) through which it communicates to other threads.
> > >
> > > The trouble is that these latter sockets (UNIX domain, SOCK_STREAM) behave
> > > like SOCK_SEQPACKET sockets, in that if I do not need read all the
> > > available data at once, it is gone (a second call to read() blocks). As
> > > far as I know this is not expected behavior for SOCK_STREAM sockets so I
> > > have a couple of possible explanations:
> > >
> > > 1. Linux kernel bug
> > > 2. Bluez bug
> > >
> > > which causes a SOCK_STREAM socket to act like a SOCK_SEQPACKET.
> > >
> > > The system is a Fedora Core 2 with kernel 2.6.8-1.521. I have tried the
> > > kernel 2.6.9-mh3 now and the problem still occurs.
> >
> > may you wanna try the AF_UNIX without the L2CAP socket and see if you
> > can reproduce it without any Bluetooth involved. If yes, then it is
> > definitiv a bug in the AF_UNIX implementation.
> >
> I did try that and I could not reproduce it which led me to believe that
> it's somehow related to Bluez.
I don't understand how BlueZ can affect the AF_UNIX part. Send us your
code for review.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel
On Tue, 16 Nov 2004, Marcel Holtmann wrote:
> Hi Catalin,
>
> > I have a small application that communicates over an L2CAP channel
> > (thus through a SOCK_SEQPACKET socket). The thread that does the
> > L2CAP communication has also some UNIX domain sockets open (AF_UNIX,
> > SOCK_STREAM) through which it communicates to other threads.
> >
> > The trouble is that these latter sockets (UNIX domain, SOCK_STREAM) behave
> > like SOCK_SEQPACKET sockets, in that if I do not need read all the
> > available data at once, it is gone (a second call to read() blocks). As
> > far as I know this is not expected behavior for SOCK_STREAM sockets so I
> > have a couple of possible explanations:
> >
> > 1. Linux kernel bug
> > 2. Bluez bug
> >
> > which causes a SOCK_STREAM socket to act like a SOCK_SEQPACKET.
> >
> > The system is a Fedora Core 2 with kernel 2.6.8-1.521. I have tried the
> > kernel 2.6.9-mh3 now and the problem still occurs.
>
> may you wanna try the AF_UNIX without the L2CAP socket and see if you
> can reproduce it without any Bluetooth involved. If yes, then it is
> definitiv a bug in the AF_UNIX implementation.
>
> Regards
>
> Marcel
I did try that and I could not reproduce it which led me to believe that
it's somehow related to Bluez.
Catalin
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel
Hi Catalin,
> I have a small application that communicates over an L2CAP channel
> (thus through a SOCK_SEQPACKET socket). The thread that does the
> L2CAP communication has also some UNIX domain sockets open (AF_UNIX,
> SOCK_STREAM) through which it communicates to other threads.
>
> The trouble is that these latter sockets (UNIX domain, SOCK_STREAM) behave
> like SOCK_SEQPACKET sockets, in that if I do not need read all the
> available data at once, it is gone (a second call to read() blocks). As
> far as I know this is not expected behavior for SOCK_STREAM sockets so I
> have a couple of possible explanations:
>
> 1. Linux kernel bug
> 2. Bluez bug
>
> which causes a SOCK_STREAM socket to act like a SOCK_SEQPACKET.
>
> The system is a Fedora Core 2 with kernel 2.6.8-1.521. I have tried the
> kernel 2.6.9-mh3 now and the problem still occurs.
may you wanna try the AF_UNIX without the L2CAP socket and see if you
can reproduce it without any Bluetooth involved. If yes, then it is
definitiv a bug in the AF_UNIX implementation.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel