On Sat, Jan 9, 2010 at 9:49 PM, Brian <[email protected]> wrote: > > > On Jan 9, 4:36 pm, Chris Morgan <[email protected]> wrote: >> Hi Brian. >> >> Yeah, c++ serialization is a pain. > > If the only option for C++ serialization were various serialization > libraries, I would agree. The C++ Middleware Writer is improving > matters. >
Cool. I'm not suggesting that its a bad thing to have its just that when you look at the c# equivalent for serializing an object to a file, Stream stream = File.Open(filename, FileMode.Create); BinaryFormatter bFormatter = new BinaryFormatter(); bFormatter.Serialize(stream, objectToSerialize); stream.Close(); it becomes apparent how useful a built in serialization system can be. If your system is only a fraction of as easy as this is then it will be a huge benefit to c++ developers. >>One reason I'm a huge fan of c#. >> >> Why not use ssl for an encrypted compressed connection to your server? > > I'm thinking about that, but my first look at openssl left a bad taste > in my > mouth. The API seemed a mess. I'm not sure yet about crypto++, but > want to explore it more. It is at least written in a much better > language > than openssl. > Looking at some old c++ code I have here I see three calls to set openssl up as a client and then you can start calling SSL_read and SSL_write on the connected socket. There is a bit of complication in checking for errors etc but it wasn't too difficult to wrap it to make it look the same as normal sockets, at least that's what I ended up doing. Oh, and I ended up with an async implementation as well since it suited the application better. >> Openssl is easy to use and a standard protocol that would save time >> from re-inventing the wheel. > > Can't I get something as good or better with crypto++? > Probably. Consider the complexity of the issue and the time you'd save by using an existing and very well tested and debugged library. You would need to consider handshaking, key exchange, all kinds of error conditions and you would still end up having to deal with the complexities of sockets. Imo its a no brainer going with an existing library. You would probably spend a lot less time figuring out how to use openssl than you would rewriting your own. Plus, if you ended up using openssl you could port your application to any other language that supported ssl without having to re-write your custom transport layer code for that language. We ended up moving from c++ to c# in multiple parts where first the server was updated to c# but the client was c++, then the client was moved to c#. Chris
-- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
