- **Comment**:
>Next steps:
>- Set DEST_DROPPABLE=False
>- Explore TIPC Multicast for MDS broadcast
MDS currently using `BSRsock` sockets for both unicast & broadcast
(implemented as multiple unicasts ) , and 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.
Fulfilling the above both requirements can NOT be achieved with exist MDS
sockets.
So we have following two option :
Option 1: Discard `DEST_DROPPABLE=False` requirement and use `BSRsock`
socket for both unicast & multicast Option 2: Introduce a new socket
for multicast and use existing `BSRsock` sockets unicast , but this may
out of order receive issues while processing recv_events at receiving process.
I have explored both option with 1000K Imm Objects ( 1 million ) , both are
working fine so we need finalized the Option 1 or 2.
---
** [tickets:#654] MDS improvements**
**Status:** accepted
**Milestone:** 4.5.FC
**Created:** Wed Dec 11, 2013 10:26 AM UTC by Hans Feldt
**Last Updated:** Tue May 27, 2014 08:55 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.
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
