[Bluez-devel] SOCK_STREAM behaving like SOCK_SEQPACKET?

[Bluez-devel] SOCK_STREAM behaving like SOCK_SEQPACKET?

[Catalin Drula]

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. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel

Re: [Bluez-devel] SOCK_STREAM behaving like SOCK_SEQPACKET?

[Marcel Holtmann]

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. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel

Re: [Bluez-devel] SOCK_STREAM behaving like SOCK_SEQPACKET?

[Catalin Drula]

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. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel

Re: [Bluez-devel] SOCK_STREAM behaving like SOCK_SEQPACKET?

[Marcel Holtmann]

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. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel