I am new to ZMQ. I find ZMQ socket implementation much simpler than winsock. But my doubt is that "can a client created using ZMQ TCP socket talk to conventional TCP server?" in other words Can my ZMQ client communicate with a TELNET server implemented using winsock?
No it cannot. ZeroMQ is a messaging library and is not just a pure socket. It uses its own protocol called ZMTP and both endpoints are required to understand it.
Yes you can. It's called a ZMQ_STREAM socket. Documentation is here: zmq_socket.txt
A socket of type ZMQ_STREAM is used to send and receive TCP data from a non-ØMQ peer, when using the tcp:// transport. A ZMQ_STREAM socket can act as client and/or server, sending and/or receiving TCP data asynchronously.
When receiving TCP data, a ZMQ_STREAM socket shall prepend a message part containing the identity of the originating peer to the message before passing it to the application. Messages received are fair-queued from among all connected peers.
When sending TCP data, a ZMQ_STREAM socket shall remove the first part of the message and use it to determine the identity of the peer the message shall be routed to, and unroutable messages shall cause an EHOSTUNREACH or EAGAIN error.
Related
A newbie question: who exact send the ACK, the transport layer or the app? I have a COM-server with particle counters to send the data to my app. Sometimes I have a lost data. When I check the Wireshark protocol I see that the packets were sent from COM-Server but failed ACK from receiver. I think that ACK is missing because the my program has the error and can't edit the data properly. My colleague says that the interface (socket) simply gets no data and can't return ACK. Who is right?
TCP is a transport layer protocol. The ACK is part of TCP. Thus the ACK is part of the transport layer and send there.
Note that there might be apps which include the transport layer (i.e user space TCP implementations) in which case the ACK is send by the app, but not in the application layer but still in the transport layer. But in most cases TCP is implemented in the kernel and is thus outside the app. See OSI or TCP/IP model for more information about these layers.
My colleague says that the interface (socket) simply gets no data and can't return ACK. Who is right?
Assuming that you are not using a user space TCP implementation: The OS kernel will ACK the data as soon as these data are put into the socket buffer of your application. It will not ACK the packet if it failed to put it into the socket buffer, i.e. if the socket buffer is full because your application failed to read the data. In this case it will also reduce the window so that the peer will not send anymore data.
I want to implement a basic message queue server. The server will be able to receive messages (byte arrays) and store them, and send messages to requesting clients.
I want to decide which protocol to base my custom protocol over.
Tcp seems natural for this kind of thing. But it seems that with Tcp, each time a client wants to send a message to the MQ server it has to establish a connection. It can't just 'send away' the message. Or, I can sustain a message between the client and MQ server, but I'm not sure that's a good idea.
So is there a way in Tcp to simply 'send a message' without establishing a connection each time? If not, what protocol should I use for this?
So is there a way in Tcp to simply 'send a message' without establishing a connection each time?
No.
If not, what protocol should I use for this?
UDP is a connectionless protocol, but it also lacks guaranteed sequencing and retransmission. You would have to build an ACK-based or NACK-based protocol over it.
What's your objection to TCP connections?
I have a VERY dumb, slow embedded device which currently sends a tiny, custom TCP message to a TCP socket on a server.
I want to change how the server works, and am looking at a message broker. Can I give RabbitMQ a custom TCP stream definition or some code that handles it, or does it only speak AMQP and I have to go for a different solution (e.g. a tiny socket server written in C that consumes TCP and spits out AMQP).
Thanks!
RabbitMQ only speaks AMQP, so the answer is no.
That said, any data can be transmitted as message payloads in AMQP, so feel free to bridge to your app that way. You'll need an "AMQP->your TCP needs" translation layer though.
I can send a tcp syn, and I receive a syn/ack back, but at that point linux sends a tcp rst because it was not linux tcp that opened the connection.
I'm wondering if I can stop the rst, or if there's another way to manually perform the handshake so I can send arbitrary packets after it.
I'm implementing a nat for a class and I'm trying to debug more effectively.
The discussion surrounding this question is probably helpful.
If you are doing this for experimental reasons (i.e. not trying to interact with real tcp services) I would recommend that you set the protocol number to 253-254 instead of the regular 6 for tcp, that should allow you to prevent the kernel from picking up on the packets that you are generating.
My question is that when a socket at the receiver-side sends an ack? At the time the application read the socket data or when the underlying layers get the data and put it in the buffer?
I want this because I want both side applications know whether the other side took the packet or not.
It's up to the operating system TCP stack when this happens, since TCP provides a stream to the application there's no guarenteed 1:1 correlation between the application doing read/writes and the packets sent on the wire and the TCP acks.
If you need to be assured the other side have received/processed your data, you need to build that into your application protocol - e.g. send a reply stating the data was received.
TCP ACKs are meant to acknowledge the TCP packets on the transmission layer not the application layer. Only your application can signal explicitly that it also has processed the data from the buffers.
TCP/IP (and therefor java sockets) will guarantee that you either successfully send the data OR get an error (exception in the case of java) eventually.