I developed a chat server using websocket in cowboy, but I want to know if the message sent by server to client success.How can I know?
Websocket is a rather thin abstraction layer on top of a conventional TCP socket. After the initial handshake the difference is minimal. So, the question is: how do I know if a data chunk was received by the remote peer? The short answer: only if the peer acknowledges it explicitly by the means of application-level protocol. Remote client will send TCP ACK packets for every data packet you will send it, but this fact is well hidden from the application for good reasons. Receiving ACK packet only means that remote TCP stack has dealt with it, but says nothing about how (and if) the client application has processed it.
Add a special "acknowledge receive" message type to your chat protocol. Include a monotonically increasing sequence number in all of your outgoing messages, and include the SN of the received message in the ACK message to know exactly how much data the client has already processed.
Related
I was reading this post and it was saying there could be an issue with deadlocks if you send too much data without receiving. Is it bad to send the whole file over in a single send call? If so then what is the correct way of doing it?
I have tried sending large files using single send calls and wait until i receive it on the other end also. Sometimes the connection hangs. Maybe it could be a deadlock or improper use?
TL;DR: there are no problems doing large send with TCP itself, but there are problems in the specific example you cite.
As for TCP in general:
Using a large sent is not a problem. The network layer of your OS will take care of everything. All you need to do is make sure is that the data gets actually transmitted to the OS, i.e. check the result of sent and retry with everything not already covered by the previous sent. sent will just block your application if it currently cannot send (write buffer full). But this requires that the server will actually receive the data. If not then the server side read buffer will fill up which causes the TCP window to decrease and ultimately the send to stop until the server is actually reading the previously sent data.
As for your specific linked example:
In your specific linked example there is an application protocol on top of TCP which changes the semantics. It is not plain TCP anymore where the client could send without receiving, but it actually requires the client to also receive data. To cite the relevant part:
The server sends one byte for every 3 bytes received.
Thus, if you send a large amount of data, then the server will send a matching amount of data back - size being one third of what you have sent. This sender emitted data will be put in the read buffer of your socket. If you don't recv then this read buffer will get full. This will cause the client network stack to signal to the server a TCP window of 0 and the server will stop sending data.
If the TCP window is 0 then the server cannot send anymore data on this socket. This means that the server will be stuck in send. If the server cannot handle recv and send on the same socket in parallel, then the server will be stuck in send and not call recv anymore - which fill fill up the server side read buffer and ultimately cause the TCP window for data from client to server to be 0 too.
In this situation both client and server will be stuck in send since nobody is receiving the data sent by the other and thus the TCP window stays 0 in both directions - deadlock.
I have a server process running that listens on a port. I can establish the connection with this port, but when I try to send data, the client reports that data has been sent, while the server never receives it.
I am using WireShark to trace the data, and I can't find the data packet I sent, which means it was never received. So here's my question. Does this mean that:
The packet has never reached the network adapter on the server side?
or,
The server process never called the receiving API (recv() or equivalent)?
In other words, are TCP packets transmitted only when the receiving side calls the receiving API, or are they transmitted automatically whenever they are sent, and the receiving API only reads the buffered data?
I'm building a distributed system and I would like asynchronous send and recv from both sides with blocking after high water mark.
PUSH/PULL sockets works great, but I wasn't able to bind a PUSH socket. Meaning I can't have a client-PUSH to server-PULL and a server-PUSH to client-PULL, if the client is behind a firewall, since the server can't connect to the client.
In the book, the following is written, but I can't find an example of it.
"REQ to DEALER: you could in theory do this, but it would break if you added a second REQ because DEALER has no way of sending a reply to the original peer. Thus the REQ socket would get confused, and/or return messages meant for another client." http://zguide.zeromq.org/php:chapter3
I only need a one-to-one connection, so this would in theory work for me.
My question is, what is the best practice to obtain asynchronous send and recv with ZeroMQ without dropping packets?
Most ZeroMQ sockets can both bind (listen on a specific port, acting as a server) and connect (acting as a client). It is usually not related to the data flow. See the guide for more info.
Try to bind on your servers PUSH socket and connect from your clients PULL socket.
I'm new to ZeroMQ and trying to figure out a design issue. My scenario is that I have one or more clients sending requests to a single server. The server will process the requests, do some stuff, and send a reply to the client. There are two conditions:
The replies must go to the clients that sent the request.
If the client disconnects, the server should queue messages for a period of time so that if the client reconnects, it can receive the messages it missed.
I am having a difficult time figuring out the simplest way to implement this.
Things I've tried:
PUB/SUB - I could tag replies with topics to ensure only the subscribers that sent their request (with their topic as their identifier) would receive the correct reply. This takes care of the routing issue, but since the publisher is unaware of the subscribers, it knows nothing about clients that disconnect.
PUSH/PULL - Seems to be able to handle the message queuing issue, but looks like it won't support my plan of having messages sent to specific clients (based on their ID, for example).
ROUTER/DEALER - Design seemed like the solution to both, but all of the examples seem pretty complex.
My thinking right now is continuing with PUB/SUB, try to implement some sort of heartbeat on the client end (allowing the server to detect the client's presence), and when the client no longer sends a heartbeat, it will stop sending messages tagged with its topic. But that seems sub-optimal and would also involve another socket.
Are there any ideas or suggestions on any other ways I might go about implementing this? Any info would be greatly appreciated. I'm working in Python but any language is fine.
To prepare the best proposition for your solution, more data about your application requirements. I have made a little research about your conditions and connnect it with my experience about ZMQ, here I present two possibilities:
1) PUSH/PULL pattern in two direction, bigger impact on scalability, but messages from server will be cached.
Server has one PULL socket to register each client and get all messages from clients. Each message should have client ID to for server knowledge where send response.
For each client - server create PUSH socket to send responses. Socket configuration was sent in register message. You can use also REQ/REP pattern for register clients (assign socket number).
Each client has own PULL socket, which configuration was sent to server in register message.
It means that server with three clients required to (example port numbers in []):
server: 1 x PULL[5555] socket, 3 x PUSH[5560,5561,5562] sockets (+ optional 1 X REQ[5556] socket for registrations, but I think it depends how you prepare client identity)
client: 1 x PUSH[5555] socket, 1 x PULL[5560|5561|5562] (one per client) (+ optional 1 X REP[5556])
You have to connect server to multiple client sockets to send responses but if client disconnects, messages will not lost. Client will get their own messages when it reconnect to their PULL socket. The disadvantage is requirements of creating few PUSH sockets on server side (number of clients).
2) PUB/SUB + PUSH/PULL or REQ/REP, static cocket configuration on server side (only 2), but server has to prepare some mechanism for retransmit or cache messages.
Server create PUB socket and PULL or REQ. Client register it identity by PULL or REQ socket. server will publish all messages to client with this identity as filter. Server use monitor() function on PUB socket to count number of connected and disconnected clients (actions: 'accept' and 'disconnect'). After 'disconnect' action server publish message to all clients to register again. For clients which not re-register, server stop publish messages.
Client create SUB socket and PUSH or REQ to register and send requests.
This solution requires maybe some cache on server side. Client could confirm each message after get it from SUB socket. It is more complicated and have to be connected with your requirement. If you just would like to know that client lost message. Client could send timestamps of last message received from server during registration. If you need guarantee that clients get all messages, you need some cache implementation. Maybe other process which subscribe all messages and delete each confirmed by client.
In this solution server with three clients required to (example port numbers in []):
server: 1 x PUB[5555] socket, 1 x REP or PULL[5560] socket + monitoring PUB socket
client: 1 x SUB[5555] socket and own identity for filter, 1 x REQ or PUSH[5560] socket
About monitoring you could read here: https://github.com/JustinTulloss/zeromq.node#monitoring (NodeJS implementation, but Python will be similar)
I think about other patterns, but I am not sure that ROUTER/DEALER or REQ/REP will cover your requirements. You should read more about patterns, because each of it is better for some solutions. Look here:
official ZMQ guide (a lot of examples and pictures)
easy ROUTER/DEALER example: http://blog.scottlogic.com/2015/03/20/ZeroMQ-Quick-Intro.html
My program is similar to a HTTP proxy, it waits for messages on an interface and it forwards them to another interface. The application uses only IOCP, both client and server sides. Sometimes, the client is slower (in a ratio of 10 or 100) than the server, which can not buffering too much data.
How can I suspend an established TCP connection then resume it without losing any message? I tried to delay the post of a new recv IOCP event, but some messages are lost.
C++/Windows 7+
I tried to delay the post of a new recv IOCP event
That should in fact do the trick. Your server side TCP connection's receive buffer would then fill up to the receive buffer size as set on your socket, at which point the socket will push back to the sending side of that socket, which - by standard means of TCP flow control - simply stops sending more packets until the receiver signals having processed more messages.
Now it depends on the sending side how long it wants to wait (timeout), before disconnecting.
"some messages are lost"
That can only happen with TCP if you get disconnected, which both the sender and the receiver will take notice of. So data isn't simply lost. It depends on your network protocol on top of TCP though whether the sender application can know how much of the messages the receiving application (your proxy, in this case) successfully processed.