1
Network / Re: TCP Send raw packet bugs
« on: April 21, 2015, 03:30:07 pm »Quote from: zsbzsb
QuoteAnd lets say you got a partial write to socket before "not ready"... what do you then do? There is no way to finish the last bytes on the outside without shifting the data before you call send again...
What? This makes no sense because if you get a partial response then you call send again with the pointer to your data just incremented to the new position.
I don't understand what you mean with "no sense", let me try to clarify :
I have already covered this but in summary: Instead of letting user deciding the pointer arithmetic and calling send again, they call send until its "Done" or break on "Error/Disconnect" with the updated ref "sent" variable. This is cleaner and safer than casting user data structure to const char * on the outside.
Quote from: zsbzsb
QuoteA) Bug:
Socket::Status TcpSocket::send(const void* data, std::size_t size) at line 220 when returning not ready will not return with written as it does not have a ref.
Read the implementation again, the send() overload that doesn't include the sent overload will return Partial if only part of the data was sent. The only difference between the two functions is that one doesn't give the user the byte count that was sent. And there is no way to eliminate this function or change the signature without breaking the API.
I understand breaking the API is not a good solution, though that does not mean the current "send" implementation is a good design, that's why the send variant without the &sent for non blocking socket should be avoided at all costs in its current form, printing a warning and call it "good enough" is ridiculous . To maintain compatibility you can have a "secure" variant with the added prefix(es) or postfix(es) to send()
Quote from: zsbzsb
QuoteB) Better design :
Return written size to the caller domain (lib user) for all send functions (important for non blocking only),
user can then call send again with the same stack variable until "Done".
The sent byte count can't be returned in all functions, it is done where appropriate. There is no issue here other than with your mindset.
As an public library, as answered above this is not good enough from an objective position, has nothing to do with my mindset, grow up and take some responsibilities.
Quote from: zsbzsb
QuoteI have forked the socket portion of the library so i no longer rely on how you fix it
Mind linking to your repo then?
I have no link for it, its also ported to amalgamation so i am not sure how useful it is.