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.
Apologies, do you mean extend it further to handle the tcp form?
That does not work at present. Sure, you can receive tcp using recvmmsg,
but you cannot use it to handle a tcp based variable length encaps where
frame lengths are set in a header. That can be done only be sequential
read() or recv() to read the frame length first, then the frame.
I can in theory add that to a unified socket backend, but this is
completely different tx and rx logic - so it will become suboptimal (and
quite ugly). It will need different tx and rx functions and appropriate
initialization to select them. I'd rather keep it to datagram only -
what says on the tin.
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.
OK. Understood.
Btw, looks like not all comments of v1 were addressed.
I will go through the comments one more time. I realized I may have
missed converting malloc to a g_memdup in a couple places.
Thanks
Best Regards,
A.
A.
--
Anton R. Ivanov
Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/
