# DataProducer/DataConsumer feature parity **URL:** \ **Category:** mediasoup libraries\ **Created:** [October 25, 2023, 12:34pm UTC](https://mediasoup.discourse.group/t/dataproducer-dataconsumer-feature-parity/5611 "2023-10-25T12:34:07Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![j1elo](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/j1elo/32/1010_2.png) [@j1elo](https://mediasoup.discourse.group/u/j1elo)\ **Post date:** [October 25, 2023, 12:34pm UTC](https://mediasoup.discourse.group/t/dataproducer-dataconsumer-feature-parity/5611/1 "2023-10-25T12:34:07Z")
Hi, I’m working with WebRTC DataChannel for an application that performs reception and sending of data directly to/from the app itself, respectively. And found a bit of confusing lack of symmetry in DataProducer/DataConsumer features, so let me ask about it: A [DataProducer](https://mediasoup.org/documentation/v3/mediasoup/api/#DataProducer): 1. Lacks an event `DataProducer.on("message", fn(message, ppid))` in SCTP transports. This could be useful to receive ingress data from a remote peer directly into the app. It would seem like there isn’t actually any technical reason to force it passing through the router towards a DataConsumer’s `"message"` event, is it? 2. Has a method `DataProducer.send(message, ppid)` in DirectTransports. Used to inject data from the app into the router. A [DataConsumer](https://mediasoup.org/documentation/v3/mediasoup/api/#DataConsumer): 1. Has an event `DataConsumer.on("message", fn(message, ppid))` in DirectTransports. Used to extract data from the router into the app. 2. **Also has** a method `DataConsumer.send(message, ppid)` in SCTP transports. Useful to send egress data from the app directly to a remote peer. Either the existence of (4) or the lack of (1) is what confused me (and I bet more users). I think there’s no harm in having more options instead of less, so would it make sense to consider **adding (1) as a feature**? * * * Extra question: Given that DataConsumer has `DataConsumer.send(message, ppid)` in SCTP transports, looks like it might make sense that it was able to work standalone and send data generated by the application, regardless of any DataProducer. Would it make sense that mediasoup allowed just creating a DataConsumer _without_ passing a DataProducer id (`DataConsumerOptions.dataProducerId`)? After all, if the need is only to egress in-app-generated SCTP data, no DataProducer is needed at all. Otherwise, a dummy of fake one can always be created, I guess. ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [October 25, 2023, 1:43pm UTC](https://mediasoup.discourse.group/t/dataproducer-dataconsumer-feature-parity/5611/2 "2023-10-25T13:43:23Z")
All those are valid topics that we are aware of already. Thunders were added (such as DataConsumer.send) to optimize things and the resulting API become hell. DataConsumer.send() was added to allow the app to send a message just to that endpoint regardless that DataConsumer is connected to a DataProducer that is connected to many other DataConsumers. DataProducer doesn’t have a “message” event because that would involve that every datachannel message received by the worker must be routed to Node (via the UnixSocket) channel just in case the app added an event listener in the Node layer. That would be bad for performance. And in flatbuffers branch (so soon in v3) we have added “subchannels” to dynamically decide which DataConsumers should receive a message sent by DataProducer.send() in server side (see Next section in CHANGELOG in flatbuffers branch). Summary: all this is gonna be reconsidered from scratch for v4 but we cannot break things in v3 or add more controversial API just to make it more symmetric. ---
**Author:** ![j1elo](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/j1elo/32/1010_2.png) [@j1elo](https://mediasoup.discourse.group/u/j1elo)\ **Post date:** [October 25, 2023, 1:53pm UTC](https://mediasoup.discourse.group/t/dataproducer-dataconsumer-feature-parity/5611/3 "2023-10-25T13:53:58Z")
Amazing. Thanks for the context and explanations. Coincidentally, I was just now reading [this](https://mediasoup.discourse.group/t/datachannel-endpoint-are-directtransports-really-needed/3211/6), > [@DataChannel endpoint: are DirectTransports really needed?](https://mediasoup.discourse.group/t/datachannel-endpoint-are-directtransports-really-needed/3211/6): > > This is a hack due to hot changes. All this will be refactored in v4. So I was starting to think that you’d rather leave it as is until a later refactoring. Still, very good to know all the info, thanks again.