On Wed, Dec 2, 2009 at 4:15 PM, Nigel Pickard <[email protected]>wrote:
> When the Java test app works, I'd say the IO stream is transparent. I > use the same simple object instance each time (have a hard coded > method that simply returns the same object so it's identical), and I > simply call the toString of the instance to see what it is (before I > call writeTo on the server side, and after I call parseFrom on the > client side). When it doesn't work, I don't even get to parsing the > input stream..... > > Concerning the IO stream types -well, I was just experimenting with > various IO stream types, and seeing if there was a difference. I > think I tried the simpler InputStream and OutputStream but couldn't > get it to work. I know for sure I could get File, Data and Object IO > streams to work without trouble (well, assuming I used the same IO > types on both client and server). > Well, InputStream and OutputStream are abstract classes. I'm not sure how you instantiated them in your tests to determine that they do not work (unless the problem you got was that you could not create an abstract OutputStream object, which has nothing to do with protobuf code). You need to provide a concrete implementation of OutputStream. writeTo() only cares about writing raw bytes to the OutputStream, so the additional methods like writeInt() and writeObject() provided by DataOutputStream and ObjectOutputStream, respectively, do not matter. The only thing that would matter is if the bytes that were passed to the write() method were not the actual bytes written. As Kenton pointed out this is the case for, say, a gzipped output stream. You would obviously need to have your reader be aware that it is reading gzipped data, rather than raw bytes. Otherwise, it doesn't matter what output stream implementation you choose, so long as it writes the bytes that are passed to the write() method. If message.writeTo(socket.getOutputStream()); does not work for you, please post a small reproducible example. > > I keep coming around to the fact that it looks like a specific data > stream type in Java does do something to the byte stream (perhaps > adding extra bytes for a header or some sort of meta information like > you mentioned? And in Java you might need the same input stream to > read it properly? I dunno -but again from my original post, I want to > make sure if I do get that series of bytes over to a C++ app, it's in > a form that can be handled.). > Anyway, I'm going to experiment further to see what I get. If I get a > simple example working, I'll post it as I'm sure I can't be the first > person with this dilemma. > > On Dec 2, 6:31 pm, Henner Zeller <[email protected]> wrote: > > Hi, > > > > transparent as in: the same data is written out that you put in. If > > you see a difference then this might be because the ObjectOutputStream > > might add something to the data you provide, such as writing > > delimiters or something. So I guess the simple write(byte[]) will not > > actually write the content of the arrays but as well the length or > > something (this is a wild guess - haven't looked at the sources, but > > it would explain what you see). > > > > Why do you use the ObjectOutputStream anyway instead of the simpler > > OutputStream ? > > > > -- > > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<protobuf%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
