0

Calling post.php via command line will send data to my web socket server. If you call the same script via browser it will not.

This issue is only happening on my local machine. Once deployed to Centos 7 with the same PHP version/setup it works correctly from browser as should.

1) Changing server binding IP to 0.0.0.0 instead of 127.0.0.1
2) Changed server and client ports

// This is our new stuff
$context = new ZMQContext();
$socket = $context->getSocket(ZMQ::SOCKET_PUSH, 'my pusher');
$socket->connect("tcp://127.0.0.1:55555");
$socket->send(json_encode($entryData));

The expected result is to output data on CLI/CMD. This is not happening locally. No errors.

user3666197
  • 1
  • 6
  • 50
  • 92
whatsmyname
  • 11
  • 1
  • 5
  • "This issue is only happening on my local machine. " Meaning something is going on your local machine perhaps, any firewalls or setups your are missing, does the port actually need to be open on the router? also wondering if you are sending on the correct IP? did you check if you could do "ping 127.0.0.1" with off course the correct IP. – Jasper Lankhorst Nov 09 '19 at 14:55
  • How can you say ***"No errors."*** when your MCVE-code above does not even try to check for error-state indication(s) ? – user3666197 Nov 09 '19 at 23:58

1 Answers1

0

Q : ZMQ Context is not sending data from the browser/PHP

With all respect to the observed disappointment, having lived with ZeroMQ for some time, since 2.11+ and it is some time, I would dare to say a bad word about ZeroMQ Design & Art of Zen-of-Zero.

Given your MCVE-code does not even try to collect and validate an error-free state, during the runtime, the analysis is hard to build on no details available.

Instead of guessing,
the Best Next Step is : setup a socket-Monitor to see all events LIVE

Your context-of-use works with tcp://-transport-class, so you are happy to be able to spin-off a socket-Monitor

The gallery of events, that the socket-Monitor can scan / report in live-session, as they appear -- so that one can POSACK both any expected behaviour ( and order of events ), and/or detect any unexpected event(s) -- as they appear:

ZMQ_EVENT_CONNECTED,
ZMQ_EVENT_CONNECT_DELAYED,
ZMQ_EVENT_CONNECT_RETRIED,
ZMQ_EVENT_LISTENING,
ZMQ_EVENT_BIND_FAILED,
ZMQ_EVENT_ACCEPTED,
ZMQ_EVENT_ACCEPT_FAILED,
ZMQ_EVENT_CLOSED,
ZMQ_EVENT_CLOSE_FAILED,
ZMQ_EVENT_DISCONNECTED,
ZMQ_EVENT_MONITOR_STOPPED,
ZMQ_EVENT_HANDSHAKE_FAILED,
ZMQ_EVENT_HANDSHAKE_SUCCEED

How to instantiate a ZeroMQ socket-Monitor ?

ZeroMQ uses a dual-side infrastructure, where part 1) gets instantiated "inside" the Context()-instance engine by calling the :
int zmq_socket_monitor ( void *socket, char *endpoint, int events );

This will make the first half of the work - equips the Context() with a new ( internal, equipped with an already issued internal .bind() to an inproc://-transport-class ) AccessPoint, so making it ready to get externally .connect()-ed from the second half of the socket-Monitor - an external ZMQ_PAIR-archetype-based Event-Listener ( whoever that role plays )

The part 2) of the infrastructure just .connect()-s to the part 1 and the rest is yours. API documentation defines all details about the multi-frame messages sent via this link from the monitored-Context()-instance to the hands of the monitoring-Listener.

Given the problem defined above, this socket-Monitor is sure to reflect all ZeroMQ-ZMTP/RFC-derived Events and make them reported in a natural sequence, as they appear ( if they appear ) and the Monitor-Listener can label each such with a nanosecond-exact timestamp and show them on a separate ( telemetry dedicated diagnostic ) GUI/CLI.

The zmq_socket_monitor() method lets an application thread track socket events (like connects) on a ZeroMQ socket. Each call to this method creates a ZMQ_PAIR socket and binds that to the specified inproc:// endpoint. To collect the socket events, you must create your own ZMQ_PAIR socket, and connect that to the endpoint.

The events argument is a bitmask of the socket events you wish to monitor, see Supported events below. To monitor all events, use the event value ZMQ_EVENT_ALL.

NOTE: as new events are added, the catch-all value will start returning them. An application that relies on a strict and fixed sequence of events must not use ZMQ_EVENT_ALL in order to guarantee compatibility with future versions.

Each event is sent as two frames. The first frame contains an event number (16 bits), and an event value (32 bits) that provides additional data according to the event number. The second frame contains a string that specifies the affected TCP or IPC endpoint.

For a sample monitor-decoder code, may look here.

user3666197
  • 1
  • 6
  • 50
  • 92