[go-nuts] Communicating through net.Conn from multiple goroutines

Hi,

I'm trying to implement scgi protocol support to an existing xmlrpc
library, using a custom rpc.ClientCodec.
My problem is, that the ClientCodec in the ReadResponseHeader expecting to
set at least the "Seq" field of the Response struct.
As I understand from the source, it must match with the original "Seq" from
the Request, otherwise may the wrong "Call" will return to the client.
The problem is, that the xmlrpc response does not provide the "Seq" number,
neither the original "ServiceMethod" or arguments.
So if 2 rpc method invoked through the same Client from multiple goroutine,
I can't identify in the response which one returned.
The obvious solution to do the calls sequentially, communicating between
the "WriteRequest" and "ReadResponseHeader" calls with a channel for
example, but it's ugly.

I thinking an other way, where creating a struct, saving the "Seq" and
"ServiceMethod" and fire a separate goroutine, which do the call and read
the response, save it to the same struct, then send it to the
"ReadResponseHeader" method, through a channel.
This way I could be able to match the responses and the "Seq" id-s, I'm
unsure only one thing.
The documentation of the net.Conn says, "Multiple goroutines may invoke
methods on a Conn simultaneously", which is good, but what if:
Calling a long running rpc method from the A goroutine and a short running
one from the B goroutine.
It means the "WriteRequest" will be invoked 2 times, so I creating 2
struct, e.g.: with "Seq" 0(A) and 1(B) and trying to read the responses
from 2 separate goroutine.
I assume(depend from the server) it would be possible that the goroutine
with "Seq" 0 read the response of the "Seq" 1 request, because the server
finish earlier with the shorter rpc method.
In this case, 2 goroutine waits to read from the connection and when it's
ready to receive, the go scheduler will pick one randomly, so may the
responses will reverse.
Am I right?
If so, is there a way to make the rpc calls concurrent safely, without
reversing the responses?

Thanks,
Norbert