search

randomsync / robotframework-mqttlibrary

MQTT Keyword Library for Robot Framework
Apache License 2.0
25 stars 30 forks source link

Socket error on client ***, disconnecting while trying to subscribe through robot framework #8

Closed aswathykrishnan92 closed 5 years ago

aswathykrishnan92 commented 5 years ago

So. I have brought up a mosquitto broker using mosquitto -v. I have subscribed to topic MQTTTest2 and published for which I am getting the publish message correctly.

I try to replicate this via robot framework. I am able to publish a message just fine. But when I try to subscribe to the topic, I am getting a socket exception

1544001640: Sending PINGRESP to mosqsub|12144-BLRKEC334 1544001654: New connection from 127.0.0.1 on port 1883. 1544001654: New client connected from 127.0.0.1 as g:qmePxeTV?=tmm7?22Y9nZD2 aoGIQk[M[FhiQnB>v\A8[Z64AF>\tbPx3K (c1, k60). 1544001654: No will message specified. 1544001654: Sending CONNACK to g:qmePxeTV?=tmm7?22Y9nZD2A?aoGIQk[M[FhiQnB>v\ [Z64AF>\tbPx3K (0, 0) 1544001654: Received PUBLISH from g:qmePxeTV?=tmm7?22Y9nZD2A?aoGIQk[M[FhiQnB \A8[Z64AF>\tbPx3K (d0, q2, r0, m1, 'MQTTTest2', ... (11 bytes)) 1544001654: Sending PUBREC to g:qmePxeTV?=tmm7?22Y9nZD2A?aoGIQk[M[FhiQnB>v\A [Z64AF>\tbPx3K (Mid: 1) 1544001654: Received PUBREL from g:qmePxeTV?=tmm7?22Y9nZD2A?aoGIQk[M[FhiQnB> A8[Z64AF>\tbPx3K (Mid: 1) 1544001654: Sending PUBCOMP to g:qmePxeTV?=tmm7?22Y9nZD2A?aoGIQk[M[FhiQnB>v\ [Z64AF>\tbPx3K (Mid: 1) 1544001654: Sending PUBLISH to mosqsub|12144-BLRKEC334 (d0, q0, r0, m0, 'MQTTT t2', ... (11 bytes)) 1544001654: Sending PUBLISH to mosqsub|1540-BLRKEC3344 (d0, q0, r0, m0, 'MQTTT t2', ... (11 bytes)) 1544001654: Received DISCONNECT from g:qmePxeTV?=tmm7?22Y9nZD2A?aoGIQk[M[Fhi B>v\A8[Z64AF>\tbPx3K 1544001654: Client g:qmePxeTV?=tmm7?22Y9nZD2A?aoGIQk[M[FhiQnB>v\A8[Z64AF>\t x3K disconnected. 1544001654: New connection from 127.0.0.1 on port 1883. 1544001654: New client connected from 127.0.0.1 as 1589-BLRKEC3344 (c1, k60). 1544001654: No will message specified. 1544001654: Sending CONNACK to 1589-BLRKEC3344 (0, 0) 1544001654: Received SUBSCRIBE from 1589-BLRKEC3344 1544001654: MQTTTest2 (QoS 2) 1544001654: 1589-BLRKEC3344 2 MQTTTest2 1544001654: Sending SUBACK to 1589-BLRKEC3344 1544001656: Socket error on client 1589-BLRKEC3344, disconnecting.

Below is the code I used: Publish Connect 127.0.0.1 Publish topic=MQTTTest2 message=test message [Teardown] Disconnect Subsribe and Validate Connect 127.0.0.1 client_id=1589-BLRKEC3344 Subscribe and Validate topic=MQTTTest2 qos=1 payload=test [Teardown] Disconnect

The publish part is working fine and I am able to see the message in cmd window. But the subscribe part gives socket exception. Please not that I have given the clientID randomly with reference to the Ping request from the other subscribers already started. I tried with and without client id. I am having the same issue. Please help me out?

aswathykrishnan92 commented 5 years ago

@randomsync Hi, were you able to check this?

randomsync commented 5 years ago

Hi @aswathykrishnan92

  1. Please format the description so it's easier to follow. Specifically the code will be much more readable if it's enclosed in code block. For example: 
    | *Test Cases*
| Publish and Subscribe
| | Connect                 | 127.0.0.1
| | Publish                 | topic=MQTTTest2       | message=test message
| | [Teardown]              | Disconnect
  2. I'm trying to reconcile the stackoverflow question here and this issue. Seems like you were earlier getting the socket exception when you were not connecting in the Subscribe keyword. But your code snippet above does have Connect, so I'm not entirely sure if the error message in this issue description has been updated.
  3. With that said, I believe you could be running into issues because the client hasn't subscribed previously: For an MQTT subscriber to receive messages that were delivered while it was disconnected, first it has to have clean session set to false and it should previously have connected with the given client id. Secondly, it should have subscribed at a QOS level 1 or higher. Third, the publisher should have sent messages at qos 1 or higher. See this for a good description on QOS: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/

If you look at this pub sub test case: https://github.com/randomsync/robotframework-mqttlibrary/blob/master/tests/pubsub.txt#L14, it subscribes first with a defined client id and expects that it won't get the message. Then it publishes a message with qos 1. Then it subscribes again with same client id and qos=1 to validate that it received the message.

If you'd like to subscribe first and get the messages later (async), you can look at this test case: https://github.com/randomsync/robotframework-mqttlibrary/blob/master/tests/pubsub.txt#L158