Sorry not able to relate to Linux TIPC 2.0 Programmer's Guide in section 1.5.7.
Multicast Message Delivery.
It mention that `TIPC currently does not permit an application to send a
multicast message with the "destination droppable" setting disabled.
Consequently, TIPC will never try to return an undeliverable multicast message
to its sender. `
I interpreted that if we set destination droppable disabled , multicast is not
permitted .
I tryed setting TIPC_DEST_DROPPABLE=off in `multicast_demo` and observed that
multicast is working .So I find disconnect here . Do you think we need to get
clarity form TIPC devel list ?
---
** [tickets:#654] MDS improvements**
**Status:** accepted
**Milestone:** 4.5.FC
**Created:** Wed Dec 11, 2013 10:26 AM UTC by Hans Feldt
**Last Updated:** Mon Jun 23, 2014 11:49 AM UTC
**Owner:** Hans Feldt
Identified short comings:
- MDS does not use the segmentation/reassembly support in the underlying
transport protocol. For example TIPC accepts messages upto 66000 bytes
- The built in segmentation/reassembly is totally insecure, lost fragments are
not retransmitted and the complete message is dropped (without users knowledge)
- In TIPC mode DEST_DROPPABLE is not used at all. This means that messages can
be silently dropped at a receiving node at congestion.
Suggested improvements:
1) Introduce a variable fragmentation limit when sending messages. This needs
to be based on information received at service discovery. If the sender is
"old" use the classic 1400 byte limit. If the sender is new, first use TIPCs
segmentation/reassembly and then the MDS one.
2) Configure DEST_DROPPABLE=False and use returned messages for diagnostics (as
a first step). That means only for logging purposes and not for retransmission
(which is not possible since messages are not stored in a send queue)
I have working prototype patches for both. Will send out them shortly.
Using TIPC segmentation/reassembly gives a number of advantages:
- reduced risk of link congestion on sending node since TIPC counts messages
not bytes
- secure transport of large messages, TIPC handles retransmission
- possibly improved characteristics due to implicit use of Ethernet jumbo frames
Long term we should consider if MDS segmentation/reassembly can be removed.
Sending large messages should really be using stream sockets.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
