zeromq / gomq Goto Github PK

Hey

Hopefully it's ok to ask questions.
So, since it's pure Go, does that mean that the sending of the ZMQ message payload can be done with zero-copy mechanics? Since writing to a socket in Go does not copy, it seems very possible. But it will depend on internal buffering schemes that I know that (at least) libzmq got.

Thoughts and plans on that?

gomq should add support for REQ/REP as definied in:

• https://rfc.zeromq.org/spec:28/REQREP

The first goal is simply sending a message. We are now exchanging protocol IDs and versions successfully, so that's a start.

Some good references:

• ZMTP RFC
• libzmtp

To start with let's just get a pure Go implementation sending to a GoCZMQ Pull socket. On the Go side, I've started by using a slightly modified Channeler API from GoCZMQ. Working code should look like this:

func main() {
        // create a dealer channeler
        push, err := NewPushChanneler("tcp://127.0.0.1:9999")
        if err != nil {
            panic(err)
        }
        defer push.Destroy()

        // send a hello message
        push.SendChan <- [][]byte{[]byte("Hello")}
}

I'm not that concerned with what the internals look like or if we want to refactor things later - I assume we'll have some false starts API wise and things will evolve over time as we go forward.

I also don't care about handling connections to multiple endpoints, load balancing, or any other zmq features until we hit the milestone of completing the handshake and sending a message.

Remember: solve one problem at a time.

hi,

right now, the following code panics:

var pull *gomq.PullSocket = ...
_ = pull.(gomq.Server) // panicks, no Bind method

var push *gomq.PushSocket = ...
_ = push.(gomq.Client) // panicks, no Connect method

I have been reading the specs for pushpull: https://rfc.zeromq.org/spec:30/PIPELINE
and it's not clear to me whether a pull socket couldn't/shouldn't bind to an address.
ditto for a push socket.

The C++ implementation actually does actively test that:
https://github.com/zeromq/libzmq/blob/master/tests/test_spec_pushpull.cpp

shouldn't we add the corresponding methods to PullSocket and PushSocket to make them implement (resp.) Server and Client ?

(I can send a PR)

as specified in https://rfc.zeromq.org/spec:28/REQREP/

Is this project still in development? The readme says the code is young but there hasnt been a commit since 2020.

If development has stalled due to a technical problem, I would like to know.

Now that the initial handshake and messaging of TCP is working, it's time to start working on full ZeroMQ topology support for the CLIENT / SERVER socket type.

as specified in:

• https://rfc.zeromq.org/spec:23/ZMTP (stable)
• https://rfc.zeromq.org/spec:37/ZMTP (draft)

We've now made enough progress to step back and clean things up. Let's get tests for what we have in place at this point.

The ZMTP protocol is not yet complete, the greeting still missing the mechanism, as server, filler and the ready command.

As we only implement the NULL mechanism I would suggest to start with ZMTP v2.0 which is easier to implement.

What do you think?

gomq should add support for PUB/SUB as defined in:

• https://rfc.zeromq.org/spec:29/PUBSUB

boomer is using gomq to pull message from master like this.

Sometimes I got a panic(index out of range) from inside gomq, generated by this line.

Then I print out msg.Err, it's read tcp i/o timeout.

func (s *Socket) Recv() ([]byte, error) {
	msg := <-s.recvChannel
	if msg.MessageType == zmtp.CommandMessage {
	}
	if msg.Err != nil {
		fmt.Printf("%v\n", msg.Err)
		return []byte(""), msg.Err
		// os.Exit(-1)
	}
	return msg.Body[0], msg.Err
}

hi there,

For neugram.io (and gophernotes) we need to interact with Jupyter.
This is done via ZeroMQ.
But installing the Go bindings to the C++ library is a pain so going the pure-Go route would be neat.

In order to do this, we need multipart support (among other things.)
Fortunately, this has been implemented by @sideshowdave7:
master...sideshowdave7:master

any reason why this couldn't be integrated back into zeromq/gomq proper ?

It seems that the protocol version is upgraded to 3.1 for no reason in this PR.

https://github.com/zeromq/gomq/pull/77/files

In the rfc of zeromq, "Resource" is added to connnection metadata in version 3.1. But this PR has nothing to do with "Resource".