It seems to me that the reason each binary item is encrypted separately is so that "The server MAY choose to use a cached copy of data with the same uniqueid..." and "...interrupt packets before they are fully received if all uncached data has been received."
I understand the idea here, but it seems to me like it could cause a deadlock situation (especially sending to localhost) where the client sends some huge amount of data that the server has seen before. The server decides not to keep reading the data from the client and just writes the response. The client, however, gets blocked trying to write the data that isn't being read and never makes it to the point of reading the response. Admittedly, you'd have to be sending quite a bit of data. But, if you are for some reason, you'd need some super-careful client side code to dodge the deadlock. You'd either need non-blocking I/O set on the socket or you'd have to select(2) before each write(2) whether the other side is ready for more data (and then you'd still have to send your data in small chunks at a time). Alright, bedtime for me, Patrick -- You received this message because you are subscribed to the Google Groups "Growl Discuss" 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/growldiscuss?hl=en.
