You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
managing pause/resume dynamics for a gated exchange
communicating with underlying transport protocols
managing a data transfer libp2p protocol to augment gaps in a transport protocol
These last two are pretty weird -- the Transport interface as written is designed mostly around Graphsync, with the data transfer Libp2p protocol being "do all the libp2p communication graphsync can't do on its own".
In reality transport protocols are wildly different. It's highly unlikely that the libp2p data-transfer protocol as written will work for anything other than filling the gaps in graphsync.
In order to support multiple transport protocols, the "Transport" interface needs to be more more high level -- it probably needs to handle all network communication, with data transfer itself only handling the higher level functions that are truly transport independent.
The basic path forward, which we already have laid groudwork for is:
modify the transport interface to make it more high level:
Example:
// EventsHandler are semantic data transfer events data transfer can respond totypeEventsHandlerinterface {
// OnChannelOpened is called when we ask the other peer to send us data on the// given channel ID// return values are:// - nil = this channel is recognized// - error = ignore incoming data for this channelOnChannelOpened(chidChannelID) error// OnResponseReceived is called when we receive a response to a request// - nil = continue receiving data// - error = cancel this requestOnResponseReceived(chidChannelID, msgResponse) error// OnDataReceived is called when we receive data for the given channel ID// return values are:// - nil = proceed with sending data// - error = cancel this request// - err == ErrPause - pause this requestOnDataReceived(chidChannelID, link ipld.Link, sizeuint64) error// OnDataQueued is called when data is queued for sending for the given channel ID// return values are:// message = data transfer message along with data// err = error// - nil = proceed with sending data// - error = cancel this request// - err == ErrPause - pause this requestOnDataQueued(chidChannelID, link ipld.Link, sizeuint64) (Message, error)
// OnDataSent is called when we send data for the given channel IDOnDataSent(chidChannelID, link ipld.Link, sizeuint64) error// OnTransferQueued is called when a new data transfer request is queued in the transport layer.OnTransferQueued(chidChannelID)
// OnRequestReceived is called when we receive a new request to send data// for the given channel ID// return values are:// message = data transfer message along with reply// err = error// - nil = proceed with sending data// - error = cancel this request// - err == ErrPause - pause this request (only for new requests)// - err == ErrResume - resume this request (only for update requests)OnRequestReceived(chidChannelID, msgRequest) (Response, error)
// OnChannelCompleted is called when we finish transferring data for the given channel ID// Error returns are logged but otherwise have no effectOnChannelCompleted(chidChannelID, errerror) error// OnRequestCancelled is called when a request we opened (with the given channel Id) to// receive data is cancelled by us.// Error returns are logged but otherwise have no effectOnRequestCancelled(chidChannelID, errerror) error// OnRequestDisconnected is called when a network error occurs trying to send a requestOnRequestDisconnected(chidChannelID, errerror) error// OnSendDataError is called when a network error occurs sending data// at the transport layerOnSendDataError(chidChannelID, errerror) error// OnReceiveDataError is called when a network error occurs receiving data// at the transport layerOnReceiveDataError(chidChannelID, errerror) error// OnRestartExistingChannelRequestReceived// is called when the responding peer sends a request to restartOnRestartExistingChannelRequestReceived(chidChannelID, msgRequest) error
}
Transportistheminimuminterfacethatmustbesatisfiedtoserveasadatatransfer
transport layer. Transportsmustbeabletoopen (openisalwayscalledbythereceivingpeer)
andclosechannels, andsetataneventhandler*/typeTransportinterface {
// OpenChannel initiates an outgoing request for the other peer to send data// to us on this channel// Note: from a data transfer symantic standpoint, it doesn't matter if the// request is push or pull -- OpenChannel is called by the party that is// intending to receive dataOpenChannel(ctx context.Context,
channelIDChannelID,
root ipld.Link,
stor ipld.Node,
msgMessage) errorSendMessage(ctx, chidChannelID, messageMessage);
// CloseChannel closes the given channelCloseChannel(ctx context.Context, chidChannelID) error// SetEventHandler sets the handler for events on channelsSetEventHandler(eventsEventsHandler) error// CleanupChannel is called on the otherside of a cancel - removes any associated// data for the channelCleanupChannel(chidChannelID)
Shutdown(ctx context.Context) error
}
// PauseableTransport is a transport that can also pause and resume channelstypePauseableTransportinterface {
Transport// PauseChannel paused the given channel IDPauseChannel(ctx context.Context,
chidChannelID,
) error// ResumeChannel resumes the given channelResumeChannel(ctx context.Context,
msgMessage,
chidChannelID,
) error
}
move the data transfer protocola implementation into the graphsync transport layer implementation (possibly rename something like "graphsync-data-transfer" or look at truly augmenting the graphsync protocol to support everything needed
remove the "receiver" implementation from go data transfer manager
The text was updated successfully, but these errors were encountered:
What
Go-data-transfer performs several functions
These last two are pretty weird -- the Transport interface as written is designed mostly around Graphsync, with the data transfer Libp2p protocol being "do all the libp2p communication graphsync can't do on its own".
In reality transport protocols are wildly different. It's highly unlikely that the libp2p data-transfer protocol as written will work for anything other than filling the gaps in graphsync.
In order to support multiple transport protocols, the "Transport" interface needs to be more more high level -- it probably needs to handle all network communication, with data transfer itself only handling the higher level functions that are truly transport independent.
The basic path forward, which we already have laid groudwork for is:
Example:
The text was updated successfully, but these errors were encountered: