Hi,
is anyone involved in implementing L2CAP rfc according to the 1.2 spec?
If not I'll give it a try.
Regards,
Imre
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2005-02-09 at 15:06 +0100, ext Marcel Holtmann wrote:
> if you select SOCK_SEQPACKET and set the mode to flow control and
> retransmission then this must be negotiated and on success this can be
> used.
>
> For SOCK_STREAM only the flow control is really needed, but also having
> retransmission whould be great.
Ok, thanks for elaborating this.
--Imre
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Imre,
> > If SOCK_STREAM is requested and RFC negotiation fails, then also the
> > connection must fail. For SOCK_STREAM you need flow control.
> >
> > For SOCK_DGRAM and SOCK_RAW we don't do anything. The SOCK_DGRAM is for
> > connection-less channels and SOCK_RAW gives access to the signal channel
> > itself.
> >
> > If you use SOCK_SEQPACKET (current type) and mode > 0 then negotiate RFC
> > and if success then use it, otherwise fail.
> >
>
> Shouldn't we support the flow control only mode, so without
> retransmission? For SOCK_SEQPACKET and a specific mode value for
> example.
if you select SOCK_SEQPACKET and set the mode to flow control and
retransmission then this must be negotiated and on success this can be
used.
For SOCK_STREAM only the flow control is really needed, but also having
retransmission whould be great.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2005-02-09 at 11:18 +0100, ext Marcel Holtmann wrote:
> If SOCK_STREAM is requested and RFC negotiation fails, then also the
> connection must fail. For SOCK_STREAM you need flow control.
>
> For SOCK_DGRAM and SOCK_RAW we don't do anything. The SOCK_DGRAM is for
> connection-less channels and SOCK_RAW gives access to the signal channel
> itself.
>
> If you use SOCK_SEQPACKET (current type) and mode > 0 then negotiate RFC
> and if success then use it, otherwise fail.
>
Thanks, it got clearer now.
Shouldn't we support the flow control only mode, so without
retransmission? For SOCK_SEQPACKET and a specific mode value for
example.
--Imre
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Imre,
> > Feel free to start. I am happy to get L2CAP 1.2 support included. The
>
> Ok, we'll have already some basic stuff to support the new config
> options, I'll start then to implement the rest. L2CAP QoS could also be
> done at some point, for the moment I don't plan to add support to
> anything but 'best effort'.
don't worry too much about QoS at the moment.
> > L2CAP options now contain a mode value and this is exactly for this
> > purpose. Let the rest of the RFC config values be the defaults from the
> > specification by now. Another way to activate RFC would be to use the
> > SOCK_STREAM socket type.
> >
>
> Yes, I agree. Is it ok then to do the following?
>
> For SOCK_STREAM try to negotiate RFC, if peer doesn't accept use basic
> mode.
If SOCK_STREAM is requested and RFC negotiation fails, then also the
connection must fail. For SOCK_STREAM you need flow control.
> For SOCK_DGRAM, SOCK_RAW try to negotiate FC, if peer doesn't accept
> use basic mode.
For SOCK_DGRAM and SOCK_RAW we don't do anything. The SOCK_DGRAM is for
connection-less channels and SOCK_RAW gives access to the signal channel
itself.
If you use SOCK_SEQPACKET (current type) and mode > 0 then negotiate RFC
and if success then use it, otherwise fail.
> Other issues I was thinking about:
>
> The 1.2 spec says it's possible for L2CAP to send incorrect packets
> (with missing fragments) to upper layers with indication of the
> incorrect parts of the given packet. The only possiblity I found so far,
> is to signal that L2CAP reliability can't be guaranteed any more and
> drop the packet.
> Is there a way or is there a case at all where we should support
> applications that need such incorrect packets?
I think it is bad idea to support this and we don't really need it. This
interaction between different layers is useless from my point.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2005-02-09 at 09:48 +0100, ext Marcel Holtmann wrote:
> Hi Imre,
>
> > is anyone involved in implementing L2CAP rfc according to the 1.2 spec?
>
> not that I know of.
>
> > If not I'll give it a try.
>
> Feel free to start. I am happy to get L2CAP 1.2 support included. The
Ok, we'll have already some basic stuff to support the new config
options, I'll start then to implement the rest. L2CAP QoS could also be
done at some point, for the moment I don't plan to add support to
anything but 'best effort'.
> L2CAP options now contain a mode value and this is exactly for this
> purpose. Let the rest of the RFC config values be the defaults from the
> specification by now. Another way to activate RFC would be to use the
> SOCK_STREAM socket type.
>
Yes, I agree. Is it ok then to do the following?
For SOCK_STREAM try to negotiate RFC, if peer doesn't accept use basic
mode.
For SOCK_DGRAM, SOCK_RAW try to negotiate FC, if peer doesn't accept
use basic mode.
Other issues I was thinking about:
The 1.2 spec says it's possible for L2CAP to send incorrect packets
(with missing fragments) to upper layers with indication of the
incorrect parts of the given packet. The only possiblity I found so far,
is to signal that L2CAP reliability can't be guaranteed any more and
drop the packet.
Is there a way or is there a case at all where we should support
applications that need such incorrect packets?
Regards,
Imre
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Imre,
> is anyone involved in implementing L2CAP rfc according to the 1.2 spec?
not that I know of.
> If not I'll give it a try.
Feel free to start. I am happy to get L2CAP 1.2 support included. The
L2CAP options now contain a mode value and this is exactly for this
purpose. Let the rest of the RFC config values be the defaults from the
specification by now. Another way to activate RFC would be to use the
SOCK_STREAM socket type.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel