IOT October 2013

iot@xmpp.org

4 participants
4 discussions

Re: [IOT] [Standards] Standard for Throttling/Queueing Stanzas

by Joachim Lindborg

This is also needed in the IoT world when small devices are connected. where we have low level of computational power or are battery operated. Also co posting to the IOT list 2013/10/27 Peter Saint-Andre <stpeter(a)stpeter.im> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/27/2013 10:16 AM, Spencer MacDonald wrote: > > I have observed from the XMPPFramework mailing list and Github > > issues, that one of the biggest problems that iOS Developers have > > with including XMPP (alongside VoIP) in their iOS apps, is that > > their apps get terminated for receiving to much data while in the > > background. > > > > There are proprietary solutions that allow an XMPP client to inform > > the XMPP Server that the app is going to be put in the background. > > The XMPP Server then queues the stanzas until the client in with > > the XMPP Server, which on iOS is less than or equal to 10 minutes. > > Some solutions also filter out presence packets so only the most > > recent one is queued for each jid. > > > > I appreciate that the problem is iOS specific, but the solution can > > be generic. > > > > Is this something that should be incorporated into an XEP? or is > > there already a solution for this issue? > > This is one reason we defined SIFT: > > http://xmpp.org/extensions/xep-0273.html > > However, that might be more than we need. Perhaps something simpler > would be of interest? > > Peter > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSbZGaAAoJEOoGpJErxa2pg6UP/1PYUTvCcKo1kP5+7G+vRmkC > h573r1zTOJg4qJQfUKs1I46tzkBmbL5295owf80KH0SsKJ5KTd2f+eqtOcJhj6w2 > 8PxYIFKkxj9uo4ToMlnv7SJHcl5dTIIQphrg4KxTUbf8VJ0G8KJz3zRw1hiHz2aM > etiroiDL84KXLastoQnKKcpFleQfbhWHeSt9udvNSbWY7o+ySdOMfAUYZpfgy56+ > amYG1PDC9KPr32TEXzukoawdv/ILVrS51RGFsfMjTyaAKhIrhIEa3xm7+8IDlb1k > kicuImmibo1Yd7kg+SD3ZVvSeR7yeYb6ENfHboLxIsxcPbzOg6PSVb1GQ0qYzEnE > vZ5Z3wp2uvGt7HuedxXucbqHfJ+Io/oYId/d0n/fG8NXl+xWPa+Pb5+nkmD8zCa1 > l5pmHQkqAfVnvFItOEcYGi0whj9BXU1fngxAVRfHKfEMpFHPhd+XOLfOY9OzNgqw > V5In7hT1yrtTUB9HMb3jeXUHNXb8aL26vI82MGKgXzUkm9+mprGVb4dcl1PMsizt > 7QngxEX86rhUP2ByIQLxYW+9ptZ2B9xxkaHSnEFSZYKN/3Yo6ToEp8WwXGpDGbTD > h0DUsdnpD8yO3IvzhfwW1pS3XQiE44x2/QsxjX9lrTIc0xCdbguotOWGIvM5HVfb > ZMh/Yz5+oEaZTtFwX8FG > =AyEt > -----END PGP SIGNATURE----- > -- *Regards* Joachim Lindborg CTO, systems architect *Keynote speaker at GoGonet live IPv6 conferens 12-14 november<http://gogonetlive.com/gogonetlive-agenda.asp> * Sustainable Innovation AB Adress: Box 55998 102 16 Stockholm Besöksadress: Storgatan 31 (Malmgården) Email: Joachim.lindborg(a)sust.se, www.sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270

11 years, 1 month

Re: [IOT] [Standards] Standard for Throttling/Queueing Stanzas

by Peter Waher

Hello Spencer As Joachim mentioned, there is interest from the Internet of Things (IoT) community to create such a XEP. In fact, it is already planned because there's a need, but it is yet to be written. Anybody interested in co-authoring such a XEP is welcome to contact me. The envisioned XEP however is not IOS specific, but rather concerns battery-powered sensors, but can be applied to sensors in resource constrained networks (where bandwidth is constrained). The same solutions can be applied in the IOS case you mentioned, since it can be seen as a resource constrained device, when the application runs in the background. Peter Saint-André mentioned that the deferred XEP 0273 could solve part of this issue, by permitting the filtering of certain messages. Forwarding of offline stanzas (XEP-0160) can also be used. I.e. the bandwidth can be controlled by the device, using the presence as an indication when the server can send information. (Here battery powered sensors often go into sleep mode and wake up regularly to perform a task. They can only receive messages when awake.) Other solutions can be envisioned, for instance using presence=away to signal clients restricting them to send important messages only, queuing not as important messages for later when online, etc. Ideas are welcome. Best regards, Peter Waher From: Spencer MacDonald [mailto:spencer.macdonald.other@gmail.com] Sent: den 27 oktober 2013 13:17 To: XMPP Standards Subject: [Standards] Standard for Throttling/Queueing Stanzas I have observed from the XMPPFramework mailing list and Github issues, that one of the biggest problems that iOS Developers have with including XMPP (alongside VoIP) in their iOS apps, is that their apps get terminated for receiving to much data while in the background. There are proprietary solutions that allow an XMPP client to inform the XMPP Server that the app is going to be put in the background. The XMPP Server then queues the stanzas until the client in with the XMPP Server, which on iOS is less than or equal to 10 minutes. Some solutions also filter out presence packets so only the most recent one is queued for each jid. I appreciate that the problem is iOS specific, but the solution can be generic. Is this something that should be incorporated into an XEP? or is there already a solution for this issue? Regards Spencer

11 years, 1 month

XMPP & IoT presentation @ IEEE WG meeting

by Peter Waher

Hello Here's a XMPP & IoT presentation I held at IEEE WG meeting. Extensions for safe and interoperable communications for the Internet of Things: http://prezi.com/esosntqhewhs/ The aim was to discuss the Interoperability XEP (work in progress), but previous IoT-related XEPs were also presented. Best regards, Peter Waher Peter Waher, Gerente General [cid:image001.png@01CED18C.B11FC900] Clayster Chile S.A. Calle Blanco 1623, oficina 1402 Valparaíso, Chile Teléfono: +56-32-2122533, +56-9-64324113 Nextel CD: 46*206*14419 Skype: peter.waher Correo electrónico: peter.waher(a)clayster.com<mailto:peter.waher@clayster.com> Twitter: https://twitter.com/ClaysterLabs, https://twitter.com/PeterWaher LinkedIn: http://se.linkedin.com/in/peterwaher/ La información contenida en esta transmisión es confidencial y propietaria y no puede ser utilizada por personas distintas a su(s) destinatario(s). La utilización no autorizada de la información contenida en este correo por cualquier forma puede ser sancionada criminalmente de conformidad con la Ley Chilena e infringir normas sobre propiedad intelectual, propiedad industrial o secretos comerciales. Si ha recibido esta transmisión por error, por favor destrúyala y notifique al remitente telefónicamente, con cobro revertido o vía e-mail. Atendido que no existe certidumbre que el presente mensaje no será modificado como resultado de su transmisión por correo electrónico CLAYSTER Laboratorios Chile Limitada, no será responsable si el contenido del mismo ha sido modificado. Visite nuestra página WEB www.clayster.com<http://www.clayster.com/>. The information contained in this transmission is confidential and proprietary and it cannot be used by any person other than its addressee(s). Unauthorized use of the information contained in this transmission in any form may be punished under Chilean Law and be considered a copyright, industrial property or trade secrets infringement. If received in error, please destroy it and notify the sender by calling collect or e-mail. As there can be no certainty that this message will not be modified as a result of its transmission via e-mail, CLAYSTER Laboratorios Chile Limitada shall not be responsible if the content of the same has been modified. Visit www.clayster.com<http://www.clayster.com/>.

11 years, 1 month

Fwd: [FOSDEM] CFP for Internet of Things Devroom

by Peter Saint-Andre

FYI -------- Original Message -------- Subject: [FOSDEM] CFP for Internet of Things Devroom Date: Fri, 11 Oct 2013 12:18:17 +0200 From: Pieter Hintjens <ph(a)imatix.com> To: fosdem(a)lists.fosdem.org, devroom-managers(a)lists.fosdem.org Next February 2nd, we're organizing a [http://fosdem.org FOSDEM] devroom for the Internet of Things. We're now calling for proposals. Do you have an interesting project you'd like to present to 5,000+ free and open source developers? If you have a project you'd like to present, or a talk you want to give, please submit it via [https://penta.fosdem.org/submission FOSDEM's Pentabarf] web tool. You will create an account (if you don't have one from a previous year), and select the "Internet of Things devroom" as the track. We'll discuss and select talks on [https://groups.google.com/forum/?hl=en#!forum/iot-devroom the Google iot-devroom group]. Anyone who wants to join in the review process, please just join that group. The organizers will take the final decision on talks if there is no consensus. We'll look for talks that include a technical/developer oriented discussion or showcase covering one or more of the following topics: * FOSS solutions for machine-to-machine communication on small embedded devices. * Distributed FOSS applications in any field of interest for autonomous/self-controlled devices, (e.g. domotics, automotive, etc. * Presentation of embedded devices with one or more possibilities to join a network. * Infrastructure related (TCP/IP, mesh networking, message queuing, cross-layer solutions). * Real-life problematics and their solution (Cost of maintenance, power management, reachability). * Interoperability solutions for heterogeneous applications, devices, protocols, media. All presentations must be fully FOSS, and related to software development. The devroom will last one day, with a welcome at 9:45, and talks from 10:00 to 17:00. Provisionally, talks will last 25 minutes each, and we will have a brainstorming / hacking session from 15:30 to 17:00. The goal is to make this devroom as interesting and diverse as possible, which means we will favor talks that contrast each other. For the hacking session, proposals are welcome. We will consider running multiple parallel hacking sessions during the same time. The deadline for submissions is December 1st. If you submit late, your talk may still be considered but will have to be exceptionally interesting. The program will be finalized by December 30th. _______________________________________________ FOSDEM mailing list FOSDEM(a)lists.fosdem.org https://lists.fosdem.org/listinfo/fosdem

11 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

IOT October 2013