ch@riie@g@o m@iii@g oii shikokuchuo@@et
2023-Feb-16 15:15 UTC
[Rd] Question on non-blocking socket
> Date: Wed, 15 Feb 2023 01:24:26 +0100 > From: Ben Engbers <Ben.Engbers at Be-Logical.nl> > To: r-devel at r-project.org > Subject: [Rd] Question on non-blocking socket > Message-ID: <68ce63b0-7e91-6372-6926-59f3fcfffd25 at Be-Logical.nl> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi, > > December 27, 2021 I started a thread asking for help troubleshooting > non-blocking sockets. > While developing the RBaseX client, I had issues with the authentication > process. It eventually turned out that a short break had to be inserted > in this process between sending the credentials to the server and > requesting the status. Tomas Kalibera put me on the right track by > drawing my attention to the 'socketSelect' function. I don't know > exactly the purpose of this function is (the function itself is > documented, but I can't find any information for which situations this > function should be called.) but it sufficed to call this function once > between sending and requesting. > > I have two questions. > The first is where I can find R documentation on proper use of > non-blocking sockets and on the proper use of the socketSelect function? > > The second question is more focused on using non-blocking sockets in > general. Is it allowed to execute a read and a receive command > immediately after each other or must a short waiting loop be built in. > I'm asking this because I'm running into the same problems in a C++ > project as I did with RBaseX. > > Ben Engbers >Hi Ben, For an easier experience with sockets, you may wish to have a look at the `nanonext` package. This wraps 'NNG' and is generally used for messaging over its own protocols (req/rep, pub/sub etc.), although you can also use it for HTTP and websockets. In any case, a low level stream interface allows connecting with arbitrary sockets. Using something like `s <- stream(dial = "tcp://0.0.0.0:5555")` substituting in the actual address. This would allow you greater flexibility in sending and receiving over the bytestream without worrying so much about order and timing as per your current experience. For example, a common pattern this allows for is doing an async receive `r <- recv_aio(s)` before sending a request `send(s, "some request")`, and then query the receive result afterwards at `r$data`. I won't go into too much detail here, but as it is my own package, please feel free to reach out separately via email or github etc. Thanks, Charlie