Op 11-9-2012 14:22, d3fault schreef: > You haven't given any concrete reasons why I'm wrong, so I'll just > assume you are until you prove otherwise (WHEEEEEEEEEEE). Repeating > yourself doesn't count. > > Not every application protocol could use it... but a lot could. > > Also, responses and error codes are something else entirely. That > would be in a reply which would go through the Generic ACK'er again > back to the requester (the sender ACKs the receiver's reply). I'm only > talking about ACK'ing. The information learned/gained is that the > sender now KNOWS the receiver got it and/or processed it (as opposed > to knowing it's sitting in the receiver's transport layer... worthless > information to the sender's application layer). Can now stop the > re-transmit timeout or whatever. > > You're right about one thing: this argument is futile. It seems to me you have it all figured out, and don't need further advice. Fine. So go ahead and build it! I for one am curious what you come up with.
I think that in principle, it could be useful to have a generic message-based set of networking components that operate on top of TCP. Perhaps you could model it after the QNetworkAccessManager with the QNetworkRequest and QNetworkReply classes. I don't know what you have in mind exactly, of course, but you'd either need to provide a server-side component or design it in a way that the classes operate peer-to-peer. André _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
