[protobuf] Can't read in Java message sent from C++
Few days I'm trying to send a message from C++ to Java over the
network but unsuccessfully.
I needed to send a several messages over one connection. I'm doing
this:
//C++ side
void MainWindow::client_connected() {
GPSChatMessage msg = GPSChatMessage();
msg.set_type(proto::GPSChatMessage::AUTHORIZATION_REQUEST);
msg.mutable_auth_req_msg()-set_login(bsod);
msg.mutable_auth_req_msg()-set_password(*);
client-send(msg);
}
void Client::send(const GPSChatMessage msg) {
QDataStream to(socket);
char * buffer = new char[msg.ByteSize() + 4];
ZeroCopyOutputStream * os = new
ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char));
CodedOutputStream * cos = new CodedOutputStream(os);
cos-WriteLittleEndian32(msg.ByteSize()); //Tryed
WriteVariant32, didn't help
msg.SerializeToCodedStream(cos);
delete cos;
delete os;
to.writeBytes(buffer,msg.ByteSize() + 4);
delete buffer;
}
//Java side:
//(I have a thread, that represents user connection. from - is an
InputStream from socket.
public void run() {
while (!interrupted()) {
try {
GPSChatMessage msg = GPSChatMessage.parseDelimitedFrom(from);
handler.handle(msg);
} catch (IOException ex) {
Logger.getLogger(ClientThread.class.getName()).log(Level.SEVERE,
null, ex);
}
When I sending a message from C++, I'm getting 4 exceptions in Java:
10.07.2010 14:30:42 net.ClientThread run
SEVERE: null
com.google.protobuf.InvalidProtocolBufferException: Message missing
required fields: type
at
com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(Unknown
Source)
at proto.GPSChatProtocol$GPSChatMessage
$Builder.buildParsed(GPSChatProtocol.java:299)
at proto.GPSChatProtocol$GPSChatMessage$Builder.access
$200(GPSChatProtocol.java:247)
at proto.GPSChatProtocol
$GPSChatMessage.parseDelimitedFrom(GPSChatProtocol.java:218)
at net.ClientThread.run(ClientThread.java:54)
10.07.2010 14:30:43 net.ClientThread run
SEVERE: null
com.google.protobuf.InvalidProtocolBufferException: Message missing
required fields: type
at
com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(Unknown
Source)
at proto.GPSChatProtocol$GPSChatMessage
$Builder.buildParsed(GPSChatProtocol.java:299)
at proto.GPSChatProtocol$GPSChatMessage$Builder.access
$200(GPSChatProtocol.java:247)
at proto.GPSChatProtocol
$GPSChatMessage.parseDelimitedFrom(GPSChatProtocol.java:218)
at net.ClientThread.run(ClientThread.java:54)
10.07.2010 14:30:43 net.ClientThread run
SEVERE: null
com.google.protobuf.InvalidProtocolBufferException: Message missing
required fields: type
at
com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(Unknown
Source)
at proto.GPSChatProtocol$GPSChatMessage
$Builder.buildParsed(GPSChatProtocol.java:299)
at proto.GPSChatProtocol$GPSChatMessage$Builder.access
$200(GPSChatProtocol.java:247)
at proto.GPSChatProtocol
$GPSChatMessage.parseDelimitedFrom(GPSChatProtocol.java:218)
at net.ClientThread.run(ClientThread.java:54)
10.07.2010 14:30:43 net.ClientThread run
SEVERE: null
com.google.protobuf.InvalidProtocolBufferException: Protocol message
end-group tag did not match expected tag.
at
com.google.protobuf.InvalidProtocolBufferException.invalidEndTag(Unknown
Source)
at
com.google.protobuf.CodedInputStream.checkLastTagWas(Unknown Source)
at com.google.protobuf.AbstractMessageLite
$Builder.mergeFrom(Unknown Source)
at com.google.protobuf.AbstractMessage
$Builder.mergeFrom(Unknown Source)
at com.google.protobuf.AbstractMessage
$Builder.mergeFrom(Unknown Source)
at com.google.protobuf.AbstractMessageLite
$Builder.mergeDelimitedFrom(Unknown Source)
at com.google.protobuf.AbstractMessage
$Builder.mergeDelimitedFrom(Unknown Source)
at proto.GPSChatProtocol
$GPSChatMessage.parseDelimitedFrom(GPSChatProtocol.java:218)
at net.ClientThread.run(ClientThread.java:54)
I'm googling a lot, but I really don't know what to do. What I'm doing
wrong?
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: How to statically link protoc on linux?
Kenton Varda wrote: LDFLAGS=-static isn't good enough? Nope, something along the way eats it. -O -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Can't read in Java message sent from C++
I encountered a similar problem with reading the bytes in C++ from
data written in Java.
Solved it by swapping the bytes :
uint32_t magic_number = ntohl(magic_number_);
http://github.com/h4ck3rm1k3/OSM-Osmosis/commit/714be97af12698f83152d2c1d0e407337e82803b
mike
On Sat, Jul 10, 2010 at 1:47 PM, Maxim Leonovich lm.b...@gmail.com wrote:
Few days I'm trying to send a message from C++ to Java over the
network but unsuccessfully.
I needed to send a several messages over one connection. I'm doing
this:
//C++ side
void MainWindow::client_connected() {
GPSChatMessage msg = GPSChatMessage();
msg.set_type(proto::GPSChatMessage::AUTHORIZATION_REQUEST);
msg.mutable_auth_req_msg()-set_login(bsod);
msg.mutable_auth_req_msg()-set_password(*);
client-send(msg);
}
void Client::send(const GPSChatMessage msg) {
QDataStream to(socket);
char * buffer = new char[msg.ByteSize() + 4];
ZeroCopyOutputStream * os = new
ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char));
CodedOutputStream * cos = new CodedOutputStream(os);
cos-WriteLittleEndian32(msg.ByteSize()); //Tryed
WriteVariant32, didn't help
msg.SerializeToCodedStream(cos);
delete cos;
delete os;
to.writeBytes(buffer,msg.ByteSize() + 4);
delete buffer;
}
//Java side:
//(I have a thread, that represents user connection. from - is an
InputStream from socket.
public void run() {
while (!interrupted()) {
try {
GPSChatMessage msg = GPSChatMessage.parseDelimitedFrom(from);
handler.handle(msg);
} catch (IOException ex) {
Logger.getLogger(ClientThread.class.getName()).log(Level.SEVERE,
null, ex);
}
When I sending a message from C++, I'm getting 4 exceptions in Java:
10.07.2010 14:30:42 net.ClientThread run
SEVERE: null
com.google.protobuf.InvalidProtocolBufferException: Message missing
required fields: type
at
com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(Unknown
Source)
at proto.GPSChatProtocol$GPSChatMessage
$Builder.buildParsed(GPSChatProtocol.java:299)
at proto.GPSChatProtocol$GPSChatMessage$Builder.access
$200(GPSChatProtocol.java:247)
at proto.GPSChatProtocol
$GPSChatMessage.parseDelimitedFrom(GPSChatProtocol.java:218)
at net.ClientThread.run(ClientThread.java:54)
10.07.2010 14:30:43 net.ClientThread run
SEVERE: null
com.google.protobuf.InvalidProtocolBufferException: Message missing
required fields: type
at
com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(Unknown
Source)
at proto.GPSChatProtocol$GPSChatMessage
$Builder.buildParsed(GPSChatProtocol.java:299)
at proto.GPSChatProtocol$GPSChatMessage$Builder.access
$200(GPSChatProtocol.java:247)
at proto.GPSChatProtocol
$GPSChatMessage.parseDelimitedFrom(GPSChatProtocol.java:218)
at net.ClientThread.run(ClientThread.java:54)
10.07.2010 14:30:43 net.ClientThread run
SEVERE: null
com.google.protobuf.InvalidProtocolBufferException: Message missing
required fields: type
at
com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(Unknown
Source)
at proto.GPSChatProtocol$GPSChatMessage
$Builder.buildParsed(GPSChatProtocol.java:299)
at proto.GPSChatProtocol$GPSChatMessage$Builder.access
$200(GPSChatProtocol.java:247)
at proto.GPSChatProtocol
$GPSChatMessage.parseDelimitedFrom(GPSChatProtocol.java:218)
at net.ClientThread.run(ClientThread.java:54)
10.07.2010 14:30:43 net.ClientThread run
SEVERE: null
com.google.protobuf.InvalidProtocolBufferException: Protocol message
end-group tag did not match expected tag.
at
com.google.protobuf.InvalidProtocolBufferException.invalidEndTag(Unknown
Source)
at
com.google.protobuf.CodedInputStream.checkLastTagWas(Unknown Source)
at com.google.protobuf.AbstractMessageLite
$Builder.mergeFrom(Unknown Source)
at com.google.protobuf.AbstractMessage
$Builder.mergeFrom(Unknown Source)
at com.google.protobuf.AbstractMessage
$Builder.mergeFrom(Unknown Source)
at com.google.protobuf.AbstractMessageLite
$Builder.mergeDelimitedFrom(Unknown Source)
at com.google.protobuf.AbstractMessage
$Builder.mergeDelimitedFrom(Unknown Source)
at proto.GPSChatProtocol
$GPSChatMessage.parseDelimitedFrom(GPSChatProtocol.java:218)
at net.ClientThread.run(ClientThread.java:54)
I'm googling a lot, but I really don't know what to do. What I'm doing
wrong?
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
James
Re: [protobuf] Re: How to statically link protoc on linux?
Will it solve the libz.so.1 linking problem? Thanks, Jacky On Sat, Jul 10, 2010 at 3:11 AM, Kenton Varda ken...@google.com wrote: LDFLAGS=-static isn't good enough? On Fri, Jul 9, 2010 at 6:08 AM, Oliver Jowett oliver.jow...@gmail.comwrote: Jacky wrote: Many thanks! sorry for the late reply - I've just went back. :) I tried this: ja...@alpha:~/workspace/protobuf-2.3.0/src$ ldd protoc linux-vdso.so.1 = (0x7fff427ba000) libz.so.1 = /lib/libz.so.1 (0x7fe2e1485000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fe2e1171000) libm.so.6 = /lib/libm.so.6 (0x7fe2e0eed000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fe2e0cd6000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fe2e0ab9000) libc.so.6 = /lib/libc.so.6 (0x7fe2e0736000) /lib64/ld-linux-x86-64.so.2 (0x7fe2e16b9000) It seems like the binary file still depends on some gcc-related shared objects. I actually spent a while today dealing with the same issue, and eventually admitted defeat and gave up on trying to convince libtool and friends to behave. Instead I did this: ./configure --disable-shared make rm src/protoc make # this is just to make the link command obvious Then rerun the final invocation of g++ that libtool runs to link protoc, adding -static to it. (Yes, I know, static binaries are evil, but so is libstdc++ version skew) -O -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Can't read in Java message sent from C++
On Jul 10, 2010, at 7:47 , Maxim Leonovich wrote: ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char)); The documentation states: block_size is mainly useful for testing; in production you would probably never want to set it. So you should get rid of the sizeof(char) part. cos-WriteLittleEndian32(msg.ByteSize()); //Tryed WriteVariant32, didn't help msg.SerializeToCodedStream(cos); If you want to use Java's .parseDelimitedFrom, you *must* use WriteVarint32, because that is the format it expects the length prefix. In this case, you'll need to call ArrayOutputStream:: ByteCount() to figure out how many bytes were actually serialized. You also probably should create the ArrayOutputStream and CodedOutputStream on the stack, rather than using new. This will be slightly faster. That said, the only issue here that affects correctness is the WriteVarint32 part. The rest shouldn't matter unless I missed something. You should change your code to do that, then if you are still having problems you should try dumping the contents of the buffer on both the C++ and the Java side. Maybe the input/output is getting messed up somewhere? Good luck, Evan -- Evan Jones http://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Can't read in Java message sent from C++
I watched on both buffers: they are similar, but in C++ I can't find a leading Variant32 with size, when in Java it exists. The rests of buffers are identical. http://pic4.ru/8337 http://pic4.ru/8338 http://pic4.ru/8339 On 10 июл, 19:33, Evan Jones ev...@mit.edu wrote: On Jul 10, 2010, at 7:47 , Maxim Leonovich wrote: ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char)); The documentation states: block_size is mainly useful for testing; in production you would probably never want to set it. So you should get rid of the sizeof(char) part. cos-WriteLittleEndian32(msg.ByteSize()); //Tryed WriteVariant32, didn't help msg.SerializeToCodedStream(cos); If you want to use Java's .parseDelimitedFrom, you *must* use WriteVarint32, because that is the format it expects the length prefix. In this case, you'll need to call ArrayOutputStream:: ByteCount() to figure out how many bytes were actually serialized. You also probably should create the ArrayOutputStream and CodedOutputStream on the stack, rather than using new. This will be slightly faster. That said, the only issue here that affects correctness is the WriteVarint32 part. The rest shouldn't matter unless I missed something. You should change your code to do that, then if you are still having problems you should try dumping the contents of the buffer on both the C++ and the Java side. Maybe the input/output is getting messed up somewhere? Good luck, Evan -- Evan Joneshttp://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Can't read in Java message sent from C++
the leading variant in c++ is most likely in the wrong byte order if you are running a x86 machine. as i said, you need to flip them. mike On Sat, Jul 10, 2010 at 8:53 PM, Maxim Leonovich lm.b...@gmail.com wrote: I watched on both buffers: they are similar, but in C++ I can't find a leading Variant32 with size, when in Java it exists. The rests of buffers are identical. http://pic4.ru/8337 http://pic4.ru/8338 http://pic4.ru/8339 On 10 июл, 19:33, Evan Jones ev...@mit.edu wrote: On Jul 10, 2010, at 7:47 , Maxim Leonovich wrote: ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char)); The documentation states: block_size is mainly useful for testing; in production you would probably never want to set it. So you should get rid of the sizeof(char) part. cos-WriteLittleEndian32(msg.ByteSize()); //Tryed WriteVariant32, didn't help msg.SerializeToCodedStream(cos); If you want to use Java's .parseDelimitedFrom, you *must* use WriteVarint32, because that is the format it expects the length prefix. In this case, you'll need to call ArrayOutputStream:: ByteCount() to figure out how many bytes were actually serialized. You also probably should create the ArrayOutputStream and CodedOutputStream on the stack, rather than using new. This will be slightly faster. That said, the only issue here that affects correctness is the WriteVarint32 part. The rest shouldn't matter unless I missed something. You should change your code to do that, then if you are still having problems you should try dumping the contents of the buffer on both the C++ and the Java side. Maybe the input/output is getting messed up somewhere? Good luck, Evan -- Evan Joneshttp://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- James Michael DuPont Member of Free Libre Open Source Software Kosova and Albania flossk.org flossal.org -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Can't read in Java message sent from C++
I tried to convert msg.ByteSize() to LittleEndian and to BigEndian,
but that didn't helps.
I thought, that {0 0 0 18 ... } is the size, but no. Size is 17.
Look at screens: in C++ I have {17 8 1 26 12 ...}. In Java : {0 0 0 18
17 8 1 26 12...}
But what is {0 0 0 18} ? I have no more IO operations exept in
Client::send().
On 10 июл, 22:00, jamesmikedup...@googlemail.com
jamesmikedup...@googlemail.com wrote:
the leading variant in c++ is most likely in the wrong byte order if
you are running a x86 machine. as i said, you need to flip them.
mike
On Sat, Jul 10, 2010 at 8:53 PM, Maxim Leonovich lm.b...@gmail.com wrote:
I watched on both buffers: they are similar, but in C++ I can't find a
leading Variant32 with size, when in Java it exists. The rests of
buffers are identical.
http://pic4.ru/8337
http://pic4.ru/8338
http://pic4.ru/8339
On 10 июл, 19:33, Evan Jones ev...@mit.edu wrote:
On Jul 10, 2010, at 7:47 , Maxim Leonovich wrote:
ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char));
The documentation states:
block_size is mainly useful for testing; in production you would
probably never want to set it.
So you should get rid of the sizeof(char) part.
cos-WriteLittleEndian32(msg.ByteSize()); //Tryed
WriteVariant32, didn't help
msg.SerializeToCodedStream(cos);
If you want to use Java's .parseDelimitedFrom, you *must* use
WriteVarint32, because that is the format it expects the length
prefix. In this case, you'll need to call ArrayOutputStream::
ByteCount() to figure out how many bytes were actually serialized.
You also probably should create the ArrayOutputStream and
CodedOutputStream on the stack, rather than using new. This will be
slightly faster.
That said, the only issue here that affects correctness is the
WriteVarint32 part. The rest shouldn't matter unless I missed
something. You should change your code to do that, then if you are
still having problems you should try dumping the contents of the
buffer on both the C++ and the Java side. Maybe the input/output is
getting messed up somewhere?
Good luck,
Evan
--
Evan Joneshttp://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/protobuf?hl=en.
--
James Michael DuPont
Member of Free Libre Open Source Software Kosova and Albania
flossk.org flossal.org
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Can't read in Java message sent from C++
Ok, well then just read out 4 bytes first in java and they get your 17 8 1
0 0 0 18 might be the lenght that you are not reading first.
mike
On Sat, Jul 10, 2010 at 9:50 PM, Maxim Leonovich lm.b...@gmail.com wrote:
I tried to convert msg.ByteSize() to LittleEndian and to BigEndian,
but that didn't helps.
I thought, that {0 0 0 18 ... } is the size, but no. Size is 17.
Look at screens: in C++ I have {17 8 1 26 12 ...}. In Java : {0 0 0 18
17 8 1 26 12...}
But what is {0 0 0 18} ? I have no more IO operations exept in
Client::send().
On 10 июл, 22:00, jamesmikedup...@googlemail.com
jamesmikedup...@googlemail.com wrote:
the leading variant in c++ is most likely in the wrong byte order if
you are running a x86 machine. as i said, you need to flip them.
mike
On Sat, Jul 10, 2010 at 8:53 PM, Maxim Leonovich lm.b...@gmail.com wrote:
I watched on both buffers: they are similar, but in C++ I can't find a
leading Variant32 with size, when in Java it exists. The rests of
buffers are identical.
http://pic4.ru/8337
http://pic4.ru/8338
http://pic4.ru/8339
On 10 июл, 19:33, Evan Jones ev...@mit.edu wrote:
On Jul 10, 2010, at 7:47 , Maxim Leonovich wrote:
ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char));
The documentation states:
block_size is mainly useful for testing; in production you would
probably never want to set it.
So you should get rid of the sizeof(char) part.
cos-WriteLittleEndian32(msg.ByteSize()); //Tryed
WriteVariant32, didn't help
msg.SerializeToCodedStream(cos);
If you want to use Java's .parseDelimitedFrom, you *must* use
WriteVarint32, because that is the format it expects the length
prefix. In this case, you'll need to call ArrayOutputStream::
ByteCount() to figure out how many bytes were actually serialized.
You also probably should create the ArrayOutputStream and
CodedOutputStream on the stack, rather than using new. This will be
slightly faster.
That said, the only issue here that affects correctness is the
WriteVarint32 part. The rest shouldn't matter unless I missed
something. You should change your code to do that, then if you are
still having problems you should try dumping the contents of the
buffer on both the C++ and the Java side. Maybe the input/output is
getting messed up somewhere?
Good luck,
Evan
--
Evan Joneshttp://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/protobuf?hl=en.
--
James Michael DuPont
Member of Free Libre Open Source Software Kosova and Albania
flossk.org flossal.org
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
James Michael DuPont
Member of Free Libre Open Source Software Kosova and Albania
flossk.org flossal.org
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] ECCN
On Wed, Jul 7, 2010 at 2:55 PM, Chuck Knight chuck.a.kni...@gmail.com wrote: Does anyone have an ECCN (export control number) for this project? I don't think there is one. What makes you think one is needed? I thought that export control numbers for software were only required where cryptography is involved (although my knowledge of the subject is admittedly quite limited). - Dave -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] EOF and raw data from socket?
Hello! How to find out whether I got whole message or not if I read raw data from socket? I use Python. Regards, Alex. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] EOF and raw data from socket?
Since an outermost protobuf message does not include either a delimiter or a length, it is (for this scenario) necessary either to include your *own* message boundary mechanism, or for single messages just close the stream. The most common approach seems to be simply to include the length as a prefix. Some implementations provide simple ways of including this by default, but it depends on exactly how you want to represent it. Marc On 10 July 2010 22:05, A. Katasonov alexander.kataso...@gmail.com wrote: Hello! How to find out whether I got whole message or not if I read raw data from socket? I use Python. Regards, Alex. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- Regards, Marc -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Can't read in Java message sent from C++
On Sat, Jul 10, 2010 at 11:53 AM, Maxim Leonovich lm.b...@gmail.com wrote: I watched on both buffers: they are similar, but in C++ I can't find a leading Variant32 with size, when in Java it exists. The rests of buffers are identical. http://pic4.ru/8337 http://pic4.ru/8338 http://pic4.ru/8339 0 0 0 18 is NOT a varint. I think that something else is adding this to the front of your buffer on the C++ end -- these bytes are NOT coming from protocol buffers, as your screenshots plainly demonstrate. The 17 appears to be the varint size (it is only one byte in this case). On 10 июл, 19:33, Evan Jones ev...@mit.edu wrote: On Jul 10, 2010, at 7:47 , Maxim Leonovich wrote: ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char)); The documentation states: block_size is mainly useful for testing; in production you would probably never want to set it. So you should get rid of the sizeof(char) part. cos-WriteLittleEndian32(msg.ByteSize()); //Tryed WriteVariant32, didn't help msg.SerializeToCodedStream(cos); If you want to use Java's .parseDelimitedFrom, you *must* use WriteVarint32, because that is the format it expects the length prefix. In this case, you'll need to call ArrayOutputStream:: ByteCount() to figure out how many bytes were actually serialized. You also probably should create the ArrayOutputStream and CodedOutputStream on the stack, rather than using new. This will be slightly faster. That said, the only issue here that affects correctness is the WriteVarint32 part. The rest shouldn't matter unless I missed something. You should change your code to do that, then if you are still having problems you should try dumping the contents of the buffer on both the C++ and the Java side. Maybe the input/output is getting messed up somewhere? Good luck, Evan -- Evan Joneshttp://evanjones.ca/ -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
