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.
So far, as I see it, the end user has to write his own transport.c/h
from the samples directory in MQTTPacket.
I first thought everythying inside MQTTPacket/src was core code and
everything inside MQTTPacket/samples was sample code. At first I tried
to move the non-MQTTPacket specific code to another file, so the samples
would be clearly MQTTPacket samples, and all transport related stuff,
which is platform dependent, will stay aside and easily identifiable.
Your comments on MQTTPacket_read() being more of a sample suggested the
underlying sample/core structure was different from what I thought.
I'm experienced in networking, and have written TCP code for some
stacks. The current transport API fits OK for Berkeley-sockets-like
interfaces, and probably quite others. Callback-based event-driven
interfaces like lwIP raw API might require some tweaking, I'll let you
know when I get there, but I think it will fit nicely in the
non-blocking API.
I think we can have these two MQTTPacket_read() and MQTTPacket_readnb(),
even though packet reading is a transport issue, as the transport is a
stream with no logical separation between messages, the task of
extracting a message requires knowledge of the message structure, so it
is more an MQTT task than a transport task.
[
In MQTT-SN, however, as the transport is message based, there is no
actual need for a transport API and it could be left alone by requiring
the user to actually call his transport read and then a message parser
plus a message builder follower by a transport write.
(although I guess this will have to go in another thread in the dev list...)
]
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.
Of course, I just wanted to keep the same interface as the current getfn().
The current getfn() definition in MQTT and MQTT-SN packet readers has no
way to identify a socket (or equivalent), so the samples have a static
for simplicity. I understand MQTT-SN is more likely to have a single
"connection" at a time and didn't pay much attention to this issue, but
I (sort of) understand that a simple MQTT device might have only one
connection, while a more complex user of this very same interface (the
C++ client?) might require more simultaneous connections, so I sort of
introduced an ad hoc variable in the structure [please use C jargon as I
require more brain power to decode OO/C++ jargon (see below);^)]
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.
LOL, yes, I'm a hardware guy writing embedded firmware, I know nothing
on OO and C++, sure, nicer and shorter ;^)
I'll be pushing this to Gerrick as soon as I solve a hot issue I have
with a very complicated system.
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
