Hi Tomas,
I saw that the attached file is missing, I therefore have added it below.
In the examples in your reply from 11/27/21 8:05 PM, you use the command
'socketSelect(list(con2))'.
I have replaced my Sys.sleep() command with 'socketSelect(list(conn))'.
Execution-time for all the tests has
Op 08-12-2021 om 12:40 schreef Tomas Kalibera:
On 12/8/21 12:20 PM, Ben Engbers wrote:
Op 07-12-2021 om 23:49 schreef Ben Engbers:
The new code, which now uses a non-blocking socket, takes less than 4
seconds to execute the 53 tests. Compared to the 120 seconds when
using a blocking socket,
On 12/8/21 12:20 PM, Ben Engbers wrote:
Op 07-12-2021 om 23:49 schreef Ben Engbers:
After a long nightly session, I ended up with inserting a wait between
sending the authentication nonce and reading the status byte.
writeBin(auth, private$conn)
Sys.sleep(.1)
Accepted <- readBin(conn, what
Op 07-12-2021 om 23:49 schreef Ben Engbers:
After a long nightly session, I ended up with inserting a wait between
sending the authentication nonce and reading the status byte.
writeBin(auth, private$conn)
Sys.sleep(.1)
Accepted <- readBin(conn, what = "raw", n = 1)
The new code, which now us
Hi Tomas,
I have implemented your suggestions as follows: (I'm not certain yet if
the first check in done - total_length == 0 is realy needed)
Creating the socket:
CreateSocket = function(host, port = 1984L, username, password) {
tryCatch(
{conn <- private$conn <- socketConnection(
On 11/28/21 5:10 PM, Ben Engbers wrote:
Searching Google seems easy. But finding reaully usefull information
is often very difficult.
I alreay found hint #1. Thankfs for #2 and #3
Perhaps people who teach these things could give best recommendations
(and those may not be reading this list).
Google?
https://developer.r-project.org/Blog/public/2020/03/17/socket-connections-update/
https://www.digitalocean.com/community/tutorials/understanding-sockets
https://developer.ibm.com/tutorials/l-sockpit/
On November 27, 2021 2:36:48 PM PST, Ben Engbers wrote:
>Hi,
>
>Looks promising! Where
I'll first finish the current development but then I will see if your
suggestion is usefull.
Ben
Op 27-11-2021 om 20:19 schreef Tomas Kalibera:
On 11/27/21 8:05 PM, Tomas Kalibera wrote:
On 11/27/21 5:24 PM, Ben Engbers wrote:
Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
This is a null-
On 11/27/21 8:05 PM, Tomas Kalibera wrote:
On 11/27/21 5:24 PM, Ben Engbers wrote:
Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
This is a null-terminated message protocol [1]. It has to be
processed one byte at a time.
[1] https://docs.basex.org/wiki/Server_Protocol
The message may cont
On 11/27/21 5:24 PM, Ben Engbers wrote:
Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
This is a null-terminated message protocol [1]. It has to be
processed one byte at a time.
[1] https://docs.basex.org/wiki/Server_Protocol
The message may contain embedded 0x00's. To distinguish these emb
Maybe time to learn it. At least to assemble complete messages.
That said, the design of this protocol is intrinsically inefficient. Maybe they
will upgrade if the software gets popular.
On November 27, 2021 8:24:36 AM PST, Ben Engbers
wrote:
>Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
>>
Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
This is a null-terminated message protocol [1]. It has to be processed one byte
at a time.
[1] https://docs.basex.org/wiki/Server_Protocol
The message may contain embedded 0x00's. To distinguish these embedded
0x00's (and 0xFF's) from a terminati
This is a null-terminated message protocol [1]. It has to be processed one byte
at a time.
[1] https://docs.basex.org/wiki/Server_Protocol
On November 27, 2021 7:45:31 AM PST, Gabor Grothendieck
wrote:
>Whether the length is variable or not isn't relevant. The point is
>whether the message is
Whether the length is variable or not isn't relevant. The point is
whether the message is prefaced by a length or command from which the
length can be derived. Maybe it is not and you will have to rely on
inefficient methods but in many cases protocols are designed to avoid
such problems.
On Sat,
No, according to the specification the minimal number of bytes that is
returned is 2. There is no maximum. (When querying a database you never
know on forehand how many records match the query so by definition you
can't calculate the size of the message).
In some C, C++ or Java-code I found on
Does the message start with a length or a command whose argument length is known
depending on the particular command?
If so first read the length or command and from that the length of the
remainder of
the message can be determined.
On Sat, Nov 27, 2021 at 4:09 AM Ben Engbers wrote:
>
>
> Hi,
>
>
rdoch
Datum: 27-11-2021 12:02 (GMT+01:00) Aan:
ben.engb...@be-logical.nl, r-package-devel@r-project.org Onderwerp: Re:
[R-pkg-devel] socketConnection, delay when reading from On 27/11/2021 4:09
a.m., Ben Engbers wrote:> > Hi,> > I have been working on a R-client for the
BaseX
On 27/11/2021 4:09 a.m., Ben Engbers wrote:
Hi,
I have been working on a R-client for the BaseX XML-database and version
0.9.2 is nearly finished (submitting version 0.9.0 was rejected by CRAN).
Version 0.3 of RBaseX can be found here
(https://cran.microsoft.com/web/packages/RBaseX/index.html).
18 matches
Mail list logo
