How to handle multiple connections contexts ?

[tarundjoshi]

I am trying to create a server where server must send data that will be provided dynamically as user input to send to a particular connection.

For each connection and each stream there is a separate send and receive queue which I have created.

I am currently using Just in time api to send data on a stream from the queues.

I am wondering how to activate the stream when there is data to send on a specific connection ( from server side ) ? Since a new context is created for each new connection, how can I make the server side decide which connection and which stream to activate when data is available to send?

The main thing is that the stream data callback has contexts specific to the connection, however I want to be able to view all connections simultaneously outside the callback to decide when to activate stream for a particular connection.

One temporary fix for this would be to maintain a map of maybe an IP, port number to the corresponding connection context, and add data to a queue on some stream, and activate that stream.

Is there a better way to do this?

[huitema]

I assume that you have two threads, one for running the protocol and one for populating the queues. You can achieve that by starting the "socket loop" as a background thread -- see for example the code in sockloop_thread_test. It set flags so the generic code in sockloop_test_one follow the use_background_thread option.

Once picoquic is running in the background, you should do the following after adding a message to one of the queues:

• wake up the network thread by calling picoquic_wake_up_network_thread
• in the network loop callback picoquic_packet_loop_wake_up from the network thread, call the API picoquic_mark_active_stream with the appropriate connection context, stream ID, and application level stream context. In your case, the application level stream context should probably point to the message queue associated with the stream.

Picoquic will then do a callback picoquic_callback_prepare_to_send when the transport is ready to send data on the stream.

[tarundjoshi]

Thank you for your reply. Yes, i have two threads running one for protocol and one for populating queues. I am using the picoquic_start_custom_network_thread API for this.

However i am facing an issue now, i have an application level queue, which enqueues packets (of variable size) and the picoquic_callback_prepare_to_send uses this application level queue to send data on a single stream( the stream is always active i have put the fin bit as 0 by default) to the server. I am using mutex locks to synchronise threads.

The callback seems to get stuck when i enqueue around 10,000 - 100,000 packets at CPU speed, after which picoquic_wakeup_network_thread doesnt seem to trigger the callback at all for sending data. I want to send data only if 'length' variable in the callback is >= 10, that is only if i can send 10 bytes at once. So if i don't receive a buffer length of 10, i simply don't send data and call picoquic_mark_active_stream from within the callback again in hope that next time the callback is received, i would have greater than 10 bytes buffer available.

Does the buffer length provided not change if i do not utilise it ? Could there be any other reasons that could cause the thread to get stuck ?

[huitema]

Have you checked "Reneging on the application writing promise" in send_receive_data.md?

[tarundjoshi]

Yes, i have read this, and i am indeed trying to use this concept of 'hyper active polling'. Is the performance impact as stated in the doc the reason for the application hanging ? If so is adding a sleep duration a good strategy to increase performance ?

except in the case when the application message does not fit in the length of the buffer, maybe because some other data was already written in the outgoing packet. The next callback should provide a larger buffer.

Does this mean that otherwise a larger buffer is never provided ? Because this seems to be false, there have been occurences where simply waiting allows me to get a different buffer size. Or is this something specific to the case of hyper active polling ?

[huitema]

The documentation is correct, and I know of several applications using that logic with success. I need some kind of trace to understand what is going on.

[tarundjoshi]

Since the topic is different from the original asked topic, i will open this in a new discussion, #1819 .