FAQ
I wrote a workable simplified code in the attached file.

use 'make test' could build a simple test log under current directory.

The connection graph is like:

client 1 (cli) <-> proxy
client 2 (cli) <-> proxy
...
client n (cli) <-> proxy
proxy 1 <-> server(srv)
proxy 2 <-> server(srv)
...
proxy n <-> server(srv)


In this implementation (proxy/proxy.go), I just use a mutex to let one
command coming from client to server.
I wish it could do:
1. collect multiple command in a socket write together to server.
2. improve the process throughput by reduce the lock time.
But, I still have not any idea to improve it.

func srvProcess(srvAddr string, cmd Data, reply *Data) error {
mu.Lock()
defer mu.Unlock()
err := dialServer(&srvConn, srvAddr)
if err != nil {
return err
}
writeCmdToSrv(srvAddr, &srvConn, cmd)
err = readReplyFromSrv(srvAddr, &srvConn, reply)
return err
}

--
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

  • Tamás Gulácsi at May 24, 2013 at 9:01 am
    Have a channel, push commands (and reply structures) into it.
    Have a goroutine fetch from this channel and build buffer of commands, with a select-ed timeout. On every tick, send all commands to the server.
    You know the reply structure, maybe you'll need ids and a map to find the right reply socket.

    --
    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.
  • Dlin at May 24, 2013 at 10:01 am
    For this structure, it will cause a minimum latency is the 'tick'.
    Is there better solution? I want to implement low latency for case only one
    command sent.
    On Friday, May 24, 2013 5:01:53 PM UTC+8, Tamás Gulácsi wrote:

    Have a channel, push commands (and reply structures) into it.
    Have a goroutine fetch from this channel and build buffer of commands,
    with a select-ed timeout. On every tick, send all commands to the server.
    You know the reply structure, maybe you'll need ids and a map to find the
    right reply socket.
    --
    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.
  • Tamás Gulácsi at May 24, 2013 at 10:45 am
    How do you know that only one command is sent?
    Set a small tick if you need low latency (100ms ie)

    --
    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.
  • Henry Heikkinen at May 24, 2013 at 10:58 am
    Hi,

    Instead of ticking, you could simply buffer commands from channel until
    it's empty or some time/amount limitation is reached. See this quick
    example I wrote and feel free to tweak it:
    http://play.golang.org/p/PCrvzX_miG

    Regards,
    Henry Heikkinen


    2013/5/24 dlin <dlin.tw@gmail.com>
    For this structure, it will cause a minimum latency is the 'tick'.
    Is there better solution? I want to implement low latency for case only
    one command sent.

    On Friday, May 24, 2013 5:01:53 PM UTC+8, Tamás Gulácsi wrote:

    Have a channel, push commands (and reply structures) into it.
    Have a goroutine fetch from this channel and build buffer of commands,
    with a select-ed timeout. On every tick, send all commands to the server.
    You know the reply structure, maybe you'll need ids and a map to find the
    right reply socket.
    --
    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.

    --
    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.
  • Igor Yurchenko at May 24, 2013 at 3:58 pm
    I have two remarks only.
    1) I don't know how complex the dialServer function internally. But
    "manual" dialling on each incoming command is a bad practise. you should
    make certain thread keeping connection to the server up and closing it by
    certain timeout if the command queue becomes empty.

    2) It looks strange. You want to make lock period shorter, but defer such
    important action as unlocking. Do unlock manually right after writing
    command to server. Or, may be, after reading err status. It depend on many
    things...

    пятница, 24 мая 2013 г., 15:29:53 UTC+8 пользователь dlin написал:
    I wrote a workable simplified code in the attached file.

    use 'make test' could build a simple test log under current directory.

    The connection graph is like:

    client 1 (cli) <-> proxy
    client 2 (cli) <-> proxy
    ...
    client n (cli) <-> proxy
    proxy 1 <-> server(srv)
    proxy 2 <-> server(srv)
    ...
    proxy n <-> server(srv)


    In this implementation (proxy/proxy.go), I just use a mutex to let one
    command coming from client to server.
    I wish it could do:
    1. collect multiple command in a socket write together to server.
    2. improve the process throughput by reduce the lock time.
    But, I still have not any idea to improve it.

    func srvProcess(srvAddr string, cmd Data, reply *Data) error {
    mu.Lock()
    defer mu.Unlock()
    err := dialServer(&srvConn, srvAddr)
    if err != nil {
    return err
    }
    writeCmdToSrv(srvAddr, &srvConn, cmd)
    err = readReplyFromSrv(srvAddr, &srvConn, reply)
    return err
    }
    --
    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 24, '13 at 7:30a
activeMay 24, '13 at 3:58p
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase