This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
We (the folks at UTK) implemented a SCTP BTL. It's not yet in the
trunk, but it will get there shortly. Instead of starting from
scratch, it might be a good idea to start directly from there.
To answer your question, the TCP BTL use a copy of the original
iovec. After each write, this copy is modified in order to describe
the next operation (i.e. some of the iovec removed and some pointers
modified based on the return value of the write function).
On Jun 26, 2007, at 2:15 PM, Karol Mroz wrote:
> Hello... I'm a student at the University of British Columbia
> working on
> creating an SCTP BTL for Open MPI. I have a simple implementation
> working that uses SCTPs one-to-one style sockets for sending messages.
> The same writev()/readv() calls that are used in the TCP BTL are
> used in
> this new BTL.
> The next step is to allow large messages (300K +) to be sent over the
> SCTP socket. Right now, I'm fragmenting the iovec pointing to the
> message at the BTL level. Repeated calls to writev() are then made,
> the first call sending header information and a part of the message,
> followed by sends of nothing but message data.
> My concern is that if the send is interrupted partly through the
> and then resumed, it will attempt to resend the vector containing the
> message data from the beginning as mca_btl_sctp_frag_t pointer is only
> aware of the original, un-fragmented iovec. I'm wondering if extending
> the array of iovec structures contained within the frag pointer to
> contain the properly fragmented message would cause havoc on the
> middleware. Currently the array is of size 5 (as is the case for
> the TCP
> BTL). Would extending this beyond 5 to allow for proper book
> keeping in
> the event of an interrupted send create problems?
> Any ideas on this matter would be greatly appreciated.
> Karol Mroz
> devel mailing list
- application/pkcs7-signature attachment: smime.p7s