On Wed, 26 Jun 2019 12:08:47 +0200 Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > On 6/26/19 11:55 AM, David Jander wrote: > >> One more question regarding isolation of different sockets. Should we > >> allow a bind()+connect() to the same tuple (SRC/DST/PGN) from more than > >> one socket? We have to take care of Names, too...somehow. > > > > Good question... does that have impact on the code? Is it easier to restrict > > it to one instance, or is it easier to just sent duplicated data to the same > > kind of sockets? > > For now we receive the whole (E)TP in kernel and dump the whole message > into all matching sockets. So it doesn't make any difference here. > > We were also having incremental recv() in the back of our heads, it's > probably easier with only one socket. I agree. Can we say then, that data should be delivered on one socket only, and that it is never duplicated (except for un-connect()ed sockets maybe)? > However it probably only makes sense on connect()ed sockets, as an > ongoing huge ETP will block every small packet. And huge ETP transfers > can take up to an hour... Small interleaved single-frame messages will then be recv()ed on the bind()ed-only socket? If a client sends me (the server) a huge ETP and in between single-frame real-time messages, will that work correctly? I'd expect to receive all the single-frame messages in real-time and the ETP message at the end... Best regards, -- David Jander Protonic Holland.
