Closed jpmens closed 10 years ago
I think I could generate a unique ID, which I use until the userid is changed deliberately by the user. I would ignore the transmitted clientID from the server
The current server-side-built clientID is nice b/c it allows easier debugging
In other words, if you could POST the uuid as a string during /conf invocation, the rest could remain as is. :-)
yes, can do
will you return the clientid anyhow? This keeps us flexible!
Oh, yes, of course; that hasn't changed. I now return the MQTT clientID as follows:
'clientid' : 'iosCTRL-' + clientid + '-' + username,
^^^ returned to client ^^^ obtained from app
works well, but exceeds the MQTT 3.1.1 limit of 23 chars for clientID.
The Server MAY restrict the ClientId it allows in terms of their lengths and the characters they contain,.The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". [MQTT-3.1.3-5]
Correct. I will truncate. (Even though spec has been modified recently.)
unfortunately this part of the spec was re-introduced in the latest OASIS standard version
I will send a base32 uuid, UUIDString provided by IOS contains illegal character -
.
As I need 2 different clientIDs (clean/no-clean session), I will append a Z
to one of them.
You may want to eliminate the -
s too.
implemented in 0.5.9
CTRL obtains MQTT parameters from ctrld during the 'conf' phase, at which time we generate (server-side) an MQTT clientID which is used by the CTRL client. This clientID is based upon the username, and it must remain 'static' for that user for persistent connections.
However, this doesn't work for multiple CTRL clients on which the same user is logged in (e.g. "demo").
Should we, in CTRL, generate a UUID or some unique number thing, upon first start which is sent along to conf? ctrld would use that to construct an MQTT clientID which is then username and device-based.