FAQ
This does seem odd from the point of view of interoperability. Looking at
the rpc2.0 spec, an rpc server would be quite within its rights to expect a
request of the form
{"method":"add","params":[42,99],"id":0}

Am I missing something here?

Ed

Le lundi 16 avril 2012 18:07:17 UTC+2, Kyle Lemons a écrit :
That is how the net/rpc library works. Each function has one input, one
output.

On Sun, Apr 15, 2012 at 5:42 AM, <steve....@gmail.com <javascript:>>wrote:
I believe there is a bug in the jsonrpc library in that it only allows
the user to send a single method argument.
This client code shows the problem:

package main

import (
"net/rpc/jsonrpc"
"os"
"net"
"fmt"
)

func main() {
conn, e := net.Dial("tcp", "localhost:1234")
if e != nil {
fmt.Fprintf(os.Stderr, "Could not connect: %s\n", e)
os.Exit(1)
}
client := jsonrpc.NewClient(conn)
args := []int{42, 99}
var reply int
client.Call("add", args, &reply)
fmt.Printf("Reply: %s\n", reply)
}

You can see what it sends by running this command before running the
client:
nc -l localhost 1234
and it prints this encoded request:
{"method":"add","params":[[42,99]],"id":0}

My understanding of the above is that there is a parameter to the call -
an array of two numbers.
It appears to be impossible to call any method that requires more than
one parameter.
I would expect the encoded request to look like this instead:
{"method":"add","params":[42,99],"id":0}

I think that net/rpc/jsonrpc/client.go should have the request defined
like this instead:
type clientRequest struct {
Method string `json:"method"`
Params []interface{} `json:"params"`
Id uint64 `json:"id"`
}
which means that clientCodec.WriteRequest would look like this:
func (c *clientCodec) WriteRequest(r *rpc.Request, params []interface{})
error {
c.mutex.Lock()
c.pending[r.Seq] = r.ServiceMethod
c.mutex.Unlock()
c.req.Method = r.ServiceMethod
c.req.Params = params
c.req.Id = r.Seq
return c.enc.Encode(&c.req)
}

I would appreciate other people's opinion on this.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • André Moraes at May 27, 2013 at 8:06 pm

    On Mon, May 27, 2013 at 3:07 PM, Edouard Tavinor wrote:
    This does seem odd from the point of view of interoperability. Looking at
    the rpc2.0 spec, an rpc server would be quite within its rights to expect a
    request of the form
    {"method":"add","params":[42,99],"id":0}
    the net/jsonrpc follow the net/rpc requirements. The
    (http://www.jsonrpc.org/) say's that you can have more than one input
    parameter, but that isn't required.

    Also, there isn't a huge difference from:

    func doA(a,b,c) int

    to

    type inputA struct {
       a,b,c int
    }
    func doA(inputA) int

    --
    André Moraes
    http://amoraes.info

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Edouard Tavinor at May 27, 2013 at 8:38 pm
    Looking at the jsonrpc library in Go this would be a fairly simple thing to
    modify to allow interoperability with existing clients or servers, written
    in other languages, which pass or expect more than one parameter. Am I
    failing to see a problem here? Could it maybe be something for Go2.0?

    Ed


    Le lundi 27 mai 2013 22:06:04 UTC+2, André Moraes a écrit :
    On Mon, May 27, 2013 at 3:07 PM, Edouard Tavinor
    <edouard...@gmail.com <javascript:>> wrote:
    This does seem odd from the point of view of interoperability. Looking at
    the rpc2.0 spec, an rpc server would be quite within its rights to expect a
    request of the form
    {"method":"add","params":[42,99],"id":0}
    the net/jsonrpc follow the net/rpc requirements. The
    (http://www.jsonrpc.org/) say's that you can have more than one input
    parameter, but that isn't required.

    Also, there isn't a huge difference from:

    func doA(a,b,c) int

    to

    type inputA struct {
    a,b,c int
    }
    func doA(inputA) int

    --
    André Moraes
    http://amoraes.info
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • André Moraes at May 28, 2013 at 12:23 am

    in other languages, which pass or expect more than one parameter. Am I
    failing to see a problem here? Could it maybe be something for Go2.0?
    If you really need it, you could implement one right now, there is
    nothing blocking that in the stdlib.

    And with "go get", your package will be really easy to install.

    --
    André Moraes
    http://amoraes.info

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Steve Horsley at May 27, 2013 at 10:55 pm
    Am I missing something here? No.

      As Kyle Lemons wrote, it is WorkingAsIntended. My guess is that they
    started out with the idea that they would implement jsonrpc and then
    realised that the net/rpc library they were basing it on could only handle
    one method argument. So they decided to "bundle" all the arguments into a
    list in the client, and unbundle the list in the server. If you only want
    go-go inetroperability, this isn't an issue of course, and Kyle states that
    interoperability was not a design goal. The real fault is in continuing to
    call it jsonrpc. It does make you wonder about their other libraries though
    - how many others are not designed for interoperability with non-go
    implementations. It reminds me of Microsoft's approach to network
    standards.

    Incidentally, the jsonrpc spec is deficient (to my mind) in that it doesn't
    define how to delineate the boundaries between json objects when sending
    them over a TCP stream. The go libraries have chosen to use a \n newline to
    mark the end of a json object, which seems reasonable to me. It can then
    make use of lower-level readline() library calls.

    On 27 May 2013 19:07, Edouard Tavinor wrote:

    This does seem odd from the point of view of interoperability. Looking at
    the rpc2.0 spec, an rpc server would be quite within its rights to expect a
    request of the form
    {"method":"add","params":[42,**99],"id":0}

    Am I missing something here?

    Ed

    Le lundi 16 avril 2012 18:07:17 UTC+2, Kyle Lemons a écrit :
    That is how the net/rpc library works. Each function has one input, one
    output.
    On Sun, Apr 15, 2012 at 5:42 AM, wrote:

    I believe there is a bug in the jsonrpc library in that it only allows
    the user to send a single method argument.
    This client code shows the problem:

    package main

    import (
    "net/rpc/jsonrpc"
    "os"
    "net"
    "fmt"
    )

    func main() {
    conn, e := net.Dial("tcp", "localhost:1234")
    if e != nil {
    fmt.Fprintf(os.Stderr, "Could not connect: %s\n", e)
    os.Exit(1)
    }
    client := jsonrpc.NewClient(conn)
    args := []int{42, 99}
    var reply int
    client.Call("add", args, &reply)
    fmt.Printf("Reply: %s\n", reply)
    }

    You can see what it sends by running this command before running the
    client:
    nc -l localhost 1234
    and it prints this encoded request:
    {"method":"add","params":[[42,**99]],"id":0}

    My understanding of the above is that there is a parameter to the call -
    an array of two numbers.
    It appears to be impossible to call any method that requires more than
    one parameter.
    I would expect the encoded request to look like this instead:
    {"method":"add","params":[42,**99],"id":0}

    I think that net/rpc/jsonrpc/client.go should have the request defined
    like this instead:
    type clientRequest struct {
    Method string `json:"method"`
    Params []interface{} `json:"params"`
    Id uint64 `json:"id"`
    }
    which means that clientCodec.WriteRequest would look like this:
    func (c *clientCodec) WriteRequest(r *rpc.Request, params []interface{})
    error {
    c.mutex.Lock()
    c.pending[r.Seq] = r.ServiceMethod
    c.mutex.Unlock()
    c.req.Method = r.ServiceMethod
    c.req.Params = params
    c.req.Id = r.Seq
    return c.enc.Encode(&c.req)
    }

    I would appreciate other people's opinion on this.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • André Moraes at May 28, 2013 at 12:20 am

    interoperability was not a design goal. The real fault is in continuing to
    call it jsonrpc. It does make you wonder about their other libraries though
    - how many others are not designed for interoperability with non-go
    implementations. It reminds me of Microsoft's approach to network standards.
    I don't think Go is similar to Microsoft in this case. jsonrpc was
    designed to work with net/rpc not the other way around. They did all
    that implementation in just a few hours (just look for the initial
    talks about Go, its one with Russ Cox and Rob Pike).

    Like you said, the only thing they did wrong was call it "jsonrpc". :-)

    Other protocols are well implemented, just look at the net/http
    package. You can get a http file server with just 4 lines of code
    (with cache handling and resumable downloads).

    --
    André Moraes
    http://amoraes.info

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 27, '13 at 7:33p
activeMay 28, '13 at 12:23a
posts6
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase