ALL,
I am looking for a simple example of non-blocking socket connection that will run on Windows.
I tried to Google, but all samples are either for *nix (POSIX) or blocking sockets on Windows.
Looking thru msdn I see that it is easy to make a socket non-blocking and issue a connect(), but then you need some preparation in order to put the socket back.
So, all in all I need something on a non-blocking socket that will connect and then put it back to be blocking.
The read and write operation should be performed on the blocking socket.
The reason for a non-blocking socket is that I need a connection timeout and there is no other way than non-blocking socket. Or is there?
Thank you.
Use ACE socket wrapper facade and apply your Linux knowledge in full.
Related
I have a node.js process which has several entry points, including a tcp server, websocket server, and named pipe server. I am wondering if any interactions with these connections will be blocking.
Example: for a given connection, if there isnt anything in the buffer because the client didnt send anything yet, will this block all other code from running in the Node.js process until the client sends data?
My understanding is that node will offload I/O operations like these to the system kernel, so it wouldnt hold up the call stack.
Most likely I am getting something wrong here so please let me know! Thank you.
This is a very interesting question!
I would recommend you to start by understanding what the event loop is (reading https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/) and then understanding the difference between blocking & non-blocking calls (reading https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/).
Now we'll know a bit more about how node works behind the scenes, what blocking and non-blocking operations are and therefore we're equipped to understand and spot what will or won't block our loop.
Will a TCP connection block it? There may be a module out there that will, it really depends on each case, library, implementation.
Regarding TCP on the "native" implementation, if you're using the node.js Net module you'll find that it is a:
module [that] provides an asynchronous network API for creating stream-based TCP or IPC servers
Therefore, in principle, it will be non-blocking.
As an example, if we look at the socket.write documentation itself, we'll find that this function:
Returns true if the entire data was flushed successfully to the kernel buffer. Returns false if all or part of the data was queued in user memory. 'drain' will be emitted when the buffer is again free.
Therefore it should not block.
PS: Another interesting article on this subject is https://medium.com/#hnasr/when-nodejs-i-o-blocks-327f8a36fbd4
Happy reading, and keep an eye out for blocking function calls!
When I send msg to a WebSocket client is it blocking or non blocking code ?
ws.send(msg);
In other words, is it a good practice to wrap a send within a setTimeout ?
I am using the Node Einaros WS library but I think this question applies to many other libraries such as Socket.Io or Engine.Io too.
Firstly, to wrap a blocking function within a setTimeout is only going to delay the blocking call, right? So it wouldn't matter if you did that or not. The non-blocking nature of node comes from the fact that the underlying engine runs an event system to let you know when traditional blocking calls (such as file system retrieval) are complete.
Websockets are a "fire and forget" protocol, which I think is what you're trying to ask. The server and client do not wait for a response and instead use the same system as I mentioned above. They will 'listen' to events when they are emitted from the other side and then deal with a process. It is worth noting that websocket communication in the browser do so only under the TCP protocol, meaning if a packet is lost then it will request it again from the server. This is not usually a problem, but in a realtime game sense where milliseconds are important, this is not usually ideal.
I have a client server arch and I am using blocking win sockets. I have a read and a write thread both on the server and on the client side.
Say Client is waiting (blocked) on a read() call for server to write stuff to,
can The client write something to that socket while it is blocked on a read() call from another thread.
So does block affect full duplex bidirectonal sockets ? I understand that I will block on the read but why would it also block on the write()?
or in order for this to work do I have to use select() or poll()?
Thanks
can The client write something to that socket while it is blocked on a read() call from another thread
Yes, this is no problem at all.
Context: Linux (Ubuntu), C, ZeroMQ
I have a server which listens on ipc:// SUB ZeroMQ socket (which physically is a Unix domain socket).
I have a client which should connect to the socket, publish its message and disconnect.
The problem: If server is killed (or otherwise dies unnaturally), socket file stays in place. If client attempts to connect to this stale socket, it blocks in zmq_term().
I need to prevent client from blocking if server is not there, but guarantee delivery if server is alive but busy.
Assume that I can not track server lifetime by some external magic (e.g. by checking a PID file).
Any hints?
Non-portable solution seems to be to read /proc/net/unix and search there for a socket name.
Without showing your code all of this is guesswork... that said...
If you have a PUB/SUB pair, the PUB will hang around to make sure that its message gets through. Perhaps you're not using the right type of zmq pair. Sounds more like you have a REP/REQ pair instead.
This way, once you connect from the client (the REQ side), you can do a zmq_poll to determine if the socket is available for writing. If yes, then go ahead with your write, otherwise shutdown the client and handle the error condition (if it is an error in your system).
Maybe you can try to connect to the socket first, with your own native socket. If the connection succeeds, it's quite high possibility your publisher could work fine.
There is another solution. Don't use ipc:// sockets. Instead use something like tcp://127.0.0.101:10001. On most UNIXes that will be almost as fast as IPC because the OS recognizes that it is a local connection and shortcuts the full IP stack processing.
Is it ok to use same socket fd in multiple threads ? (over linux)
It depends on what you expect to happen, but yes you can. If you are reading UDP packets that are each a complete message this can work well. If you are reading data streams from TCP this will probably not work well.
You can have multiple threads accepting incoming connections on a socket and that can work pretty well as each thread gets one connection.
You will run into concurrency problems trying to send() or recv() (SOCK_STREAM) from multiple threads. You should use a critical section or some other means of creating serial access to send() and recv().
One standard thing to do with threads is to have the master listen() & accept(), then pass off the socket to a client thread that sends/receives/processes from that one socket. The client thread is responsible for calling close() or shutdown().