Re: [paho-dev] Embedded MQTT C Client

[Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>]

Sergio,

submitting the API would be good -- or just send me a copy of the code 
as you have it.  I want to work out what you would have to do to create 
samples for another TCP network stack.  And I'm not clear now of the 
distinction between sample and core code.

Wouldn't it be better for getfn() to take a network object as a 
parameter as well?  Then it doesn't have to use a static object.

I'm not keen on the name MQTTTransportObject for the typedef.  It's not 
an object until it's instantiated, at this point it's a type (or 
class).  MQTTTransport is fine.

Thanks!

Ian

On 09/23/2014 05:15 PM, Sergio R. Caprile wrote:
> Sure Ian,
> so far MQTT transport API, ported from MQTT-SN, and fitting the current
> MQTT samples is:
>
> int transport_open(char* host, int port);
> int transport_sendPacketBuffer(int sock, unsigned char* buf, int buflen);
> /* block until requested data is there, or socket timeout (-1) */
> int transport_getdata(unsigned char* buf, int count);
> int transport_close(int sock);
>
> [
> MQTT-SN transport API (as recently uploaded) is a little bit different
> because of the UDP transport nature:
> int transport_open(void);
> int transport_sendPacketBuffer(char* host, int port, unsigned char* buf,
> int buflen);
> /* may return -1 if no data or block, the packet reader is friendly to
> UDP */
> int transport_getdata(unsigned char* buf, int count);
> int transport_close(void);
> ]
>
> So, to accomodate TCPs stream nature and the fact that sometimes links
> are slow and all that stuff, and bare bones embedded systems can't block
> waiting for the whole data to be present, I slightly modified the
> required behaviour with a newcomer in the MQTT transport API:
>
> /* return available data, 0 if none, -1 on error */
> int transport_getdatanb(unsigned char* buf, int count);
>
> powered by a couple state machines to wait for and collect the data in
> MQTTPacket.c. The newcomer to the MQTTPacket API would be:
>
> int MQTTPacket_readnb(unsigned char* buf, int buflen,
> MQTTTransportObject *trp);
>
> where
> typedef struct {
> 	int (*getfn)(unsigned char*, int); /* must return -1 for error, 0 for
> call again, or the number of bytes read */
> 	void *nwkobj;	/* pointer to whatever the system may use to identify the
> transport */
> 	int multiplier;
> 	int rem_len;
> 	int len;
> 	char state;
> }MQTTTransportObject;
>
> I basically copied MQTTPacket_read() and MQTTPacket_decode and turned
> them into state machines (so the variables in the network object), so
> they can safely wait for data coming in an ordered fashion but with no
> logical separation, as per TCP.
> The user gets to write his transport_getdatanb() and can choose to peek
> the transport or build an intermediate buffer. The demo as it is now
> runs on top of the sockets api and actually blocks, I thought it is more
> clear to leave this to the user and not complicate the issue by toying
> with a socket interface which won't be used on a bare metal system. I
> plan to write some samples for the lwIP raw API later.
>
> So...
> I can submit these changes to Gerrick but I would like to extensively
> test the code first (maybe submit the API ?), so far it runs on my setup
> but I'd like to actually send it data in conditions closer to the ones
> it is supposed to handle.
>
> Regards
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/paho-dev

--
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto