Hi Jason, Hi Eric, hi list,
I have gone through all comments and addressed everything to which I did
not reply separately with clarifications.
Before I resubmit I have a couple of architectural questions:
1. Is it OK in its current form: UDST client which cannot be
instantiated and the others creating instances of it. I am aware that
this does not quite match the current semantics, but this keeps the
per-transport code to the minimum possible - init and (in the newest
version) optional verify and form header functions. F.e. in the next
submission raw will be init only and its data - nothing else.
2. I have updated the help, docs and the API.
3. I did not quite understand your comment on socket.c - what are you
suggesting there - do you want to fold stream mode into a common
backend? I do not think it is possible. I have tried to do surgery only
on the datagram stuff. Also, socket.c is quite old and has a violations
of current coding style and conventions. Should I fix those as a part of
the submission or this can be a separate patch?
A.
On 21/07/17 04:55, Jason Wang wrote:
On 2017年07月21日 03:12, anton.iva...@cambridgegreys.com wrote:
Hi all,
This addresses comments so far except Eric's suggestion to use
InetSocketAddressBase. If I understand correctly its intended use,
it will not be of help for protocols which have no port (raw
sockets - GRE, L2TPv3, etc).
It also includes a port of the original socket.c transport to
the new UDST backend. The relevant code is ifdef-ed so there
should be no effect on other systems.
This looks sub-optimal. If you want to do this, I would rather suggest
you just extend the socket dgram backend like what udst did now.
I think that this is would be the appropriate place to stop in this
iteration. I would prefer to have this polished, before I start
looking at sendmmsg and bulk send or some of the more unpleasant
encapsulations like geneve.
Pay attention we're softfreeze now. So the feature is for 2.11, if it
looks good, I can only queue it for 2.11.
Btw, looks like not all comments of v1 were addressed.
Thanks
A.
--
Anton R. Ivanov
Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/
