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!
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
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
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
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
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
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
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,
>
That's what I figured out also. The problem is that even when I reduce the
size to 2 bytes and there is only 1byte available in the socket, the code will
wait for 1 second which is the minimum time-out.BenVerzonden vanaf mijn Galaxy
Oorspronkelijk bericht Van: Duncan Murdoch
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
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).
The client-server protocol specifies
13 matches
Mail list logo
