Anybody can shine some light on their experience on using the PB RPC
on an asynchronous server, like whether RPC is well-designed for it or
any potential pitfalls? I find the for async server, matching a
response to the original request is kind of a pain.
--~--~-~--~~~-
Yes, we are pretty sure that we do not modify the data prior to putting
it on the wire. We have discovered a new fact, however that will
hopefully shed some light on this bizarre error. The error seems to
occur the instance the protobuf message is fragmented in the transport
layer, i.e. when it is
Replica for you
http://joingaze.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email t
Yep, as i wrote in my previous message, that was it.
Thanks for the feedback :)
mcdowella wrote:
> This is begining to sound like a well-known TCP gotcha. Like most
> stream protocols, there is nothing in the TCP protocol that marks the
> boundaries between sender write() calls; TCP sees the conn
Hi,
I was wondering if it was possible to extract the contents of a
serialized string without knowing ahead of time what kind of message
it is?
For example: I'm using tcp to send data back and fourth. On one side
I create a message and serialize the data, and on the receiving side I
'ParseFromS
Nevermind, we found the error. Apparently, the Java read() function
reads only up to one TCP frame before returning. Replace with
readFully() and it works fine.
Kenton Varda wrote:
> Are you sure that the data you are sending to the parser is exactly
> the same data that was generated by the seri
One of the major benefits of descriptor.proto, as I saw it, was that
we could get away from the hard-coded extra options as there are for
Java.
So, I've been trying to define my C# options as extensions to
FileOptions etc. However, I need to apply those options to
descriptor.proto itself, in orde
This is begining to sound like a well-known TCP gotcha. Like most
stream protocols, there is nothing in the TCP protocol that marks the
boundaries between sender write() calls; TCP sees the connection as a
contiguous stream of bytes. If the protobuf message is fragmented into
multiple tcp frames b
You can create a message like this:
message Container {
// One of the following will be filled in.
optional Ping ping = 1;
optional StatusUpdate status_update = 2;
optional FindWorker find_worker = 3;
}
Now send Containers over the wire instead of instances of the individual
message types
Yeah, I think special-casing descriptor.proto might be the only way. :(
On Tue, Oct 14, 2008 at 12:28 PM, Jon Skeet <[EMAIL PROTECTED]> wrote:
>
> One of the major benefits of descriptor.proto, as I saw it, was that
> we could get away from the hard-coded extra options as there are for
> Java.
>
On Oct 15, 1:52 am, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> Yeah, I think special-casing descriptor.proto might be the only way. :(
Never mind. I think it will actually keep the main codebase cleaner,
as it happens. The descriptor parsing really doesn't like seeing
extensions or unknown fiel
11 matches
Mail list logo
