I am in the middle of learning Winsock and came across a conceptual problem in getting notification of request completion status from server. As client is designed only to send while server to receive, is there any way that a client can be notified? Thanks.
The server side socket that is used when you call recv can also be used to send data. Remember that the SOCKET struct that you get when you accept a client on the server is the same as the SOCKET struct on the client side that is used to connect. Thus after receiving data from the client, you can send a reply like
send(s, res_str, strlen(res_str), 0);
Where res_str is your response string. Technically res_str is strlen(res_str) + 1 bytes in size but we don't want the null character.
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.
We are building a websocket server via golang+gin+json+gorilla websocket to push messages from server side to browser.
We plan to provide frontend with some subscription command, which means messages from server side will be sent to those users who subscribed target topic.
My confusion is whether we need add Ack mechanism here? For example, when client subscribe one topic, the server saved this mapping: user --> topic.
Is it necessary for the server to send a response for each subscription request to clients (Like that we do for an RPC request)? And how to do that? Below is my consumption
type MsgHeader struct {
ReqId string `json: reqId`
Cmd string `json: cmd`
// either of "req" or "rsp"
// is it necessary to have this field???
Type string `json: type`
}
I mean the application level acknowledgement, like what we do for RPC requests. For RPC request, we send responses even when the response itself is empty, something like:
type SubscriptionRsp struct {
Code int
Msg string
Data interface{}
}
No, it's not necessary.
The Websocket specs (RFC 6455) does not mandate this.
A data frame MAY be transmitted by either the client or the server at
any time after opening handshake completion and before that endpoint
has sent a Close frame
Nothing else about acknowledging messages is said in the Sending and Receiving Data section.
Therefore any ACK is entirely an implementation detail of your application. It may be useful if you develop a resilient client that retries failed messages, where "failed" could a message that is successfully sent to the server but not processed as expected.
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 implementing a distributed system for a project and am a bit confused as to how I should properly implement the Req/Res pattern. Basically I have a few endpoints that will send a request to a client for processing tasks and responding.
So basically:
Incoming request is received
The endpoint opens a req and res socket type with the broker
Broker receives the request, proxies it to an available worker
Worker responds and the endpoint receives the processed value, reports it back via the endpoint.
I've found a decent load balance broker script here: http://zguide.zeromq.org/js:lbbroker. There's also an async client/server pattern I'm interested in implementing: http://zguide.zeromq.org/js:asyncsrv which I might adapt into a load balanced implementation.
My question is perhaps a bit simplistic but, would each endpoint open a new socket on EVERY request or maintain and open socket for every request? That means there would be n connections for every request made to the endpoint.
You'd keep the sockets open, there's no need to close them after each request. And there'd be a single socket one every endpoint (client and server). At the server end you read a request from the socket, and write your response back to the socket; zmq takes care of ensuring that the response goes back from the right client.
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.