| Ctiny_dlna::ActionReply | |
| Ctiny_dlna::ActionRequest | |
| ▼Ctiny_dlna::Allocator | Memory allocateator which uses malloc |
| Ctiny_dlna::AllocatorExt | Memory allocateator which uses ps_malloc (on the ESP32) and if this fails it resorts to malloc |
| Ctiny_dlna::Argument | DLNA Service: Action Argument |
| Ctiny_dlna::DLNAControlPointMgr | Setup of a Basic DLNA Control Point. The control point |
| Ctiny_dlna::DLNAControlPointRequestParser | Translates DLNA UDP Requests to Schedule so that we can schedule a reply |
| ▼Ctiny_dlna::DLNADevice | Device Attributes and generation of XML using urn:schemas-upnp-org:device-1-0. We could just return a predefined device xml document, but we provide a dynamic generation of the service xml which should be more memory efficient. Strings are represented as char*, so you can assign values that are stored in ProgMem to mimimize the RAM useage. If you need to keep the values on the heap you can use addString() method |
| Ctiny_dlna::MediaRenderer | MediaRenderer DLNA Device |
| Ctiny_dlna::DLNADeviceMgr | Setup of a Basic DLNA Device service. The device registers itself to the network and answers to the DLNA queries and requests. A DLNA device uses UDP, Http, XML and Soap to discover and manage a service, so there is quite some complexity involved: |
| Ctiny_dlna::DLNADeviceRequestParser | Translates DLNA UDP Requests to Schedule so that we can schedule a reply |
| Ctiny_dlna::DLNAServiceInfo | Attributes needed for the DLNA Service Definition |
| Ctiny_dlna::HttpChunkWriter | Writes the data chunked to the actual client |
| ▼Ctiny_dlna::HttpHeader | In a http request and reply we need to process header information. With this API we can define and query the header information. The individual header lines are stored in a list. This is the common functionality for the HttpRequest and HttpReplyHeader subclasses |
| Ctiny_dlna::HttpReplyHeader | Reading and Writing of Http Replys |
| Ctiny_dlna::HttpRequestHeader | Reading and writing of Http Requests |
| Ctiny_dlna::HttpHeaderLine | A individual key - value header line |
| ▼Ctiny_dlna::HttpLineReader | We read a single line. A terminating 0 is added to the string to make it compliant for c string functions |
| Ctiny_dlna::HttpChunkReader | Http might reply with chunks. So we need to dechunk the data. see https://en.wikipedia.org/wiki/Chunked_transfer_encoding |
| Ctiny_dlna::HttpParameters | API for http parameters: key=value&key1=value1 |
| Ctiny_dlna::HttpRequest | Simple API to process get, put, post, del http requests I tried to use Arduino HttpClient, but I did not manage to extract the mime type from streaming get requests |
| Ctiny_dlna::HttpRequestHandlerLine | Used to register and process callbacks |
| Ctiny_dlna::HttpRequestRewrite | Object which information about the rewrite rule |
| Ctiny_dlna::HttpServer | A Simple Header only implementation of Http Server that allows the registration of callback functions. This is based on the Arduino Server class |
| Ctiny_dlna::HttpStreamCopy | Processing of a single stream to a single client. In the loop we can simply provide individual small chunks until we are done |
| ▼Ctiny_dlna::HttpStreamedOutput | Abstract class for handling streamed output |
| Ctiny_dlna::HttpStreamedMultiOutput | Generic HttpStreamedMultiOutput Class which handles multicast streaming. We can optionally define some default (e.g. html) content that will be written at the beginning and at the end of the streaming session to the client |
| Ctiny_dlna::HttpTunnel | Forwards a request to a destination URL and provides a pointer to the result stream |
| Ctiny_dlna::Icon | Information about the icon |
| Ctiny_dlna::IPAddressAndPort | IP Adress including Port information |
| Ctiny_dlna::List< T >::Iterator | |
| Ctiny_dlna::Vector< T >::iterator | Iterator for the Vector class |
| ▼Ctiny_dlna::IUDPService | Abstract Interface for UDP API |
| Ctiny_dlna::UDPAsyncService | Access to UDP functionality: sending and receiving of data using the Async API of the ESP32 |
| Ctiny_dlna::UDPService | Access to UDP functionality: sending and receiving of data It seems that the UDP receive is not working for |
| Ctiny_dlna::List< T > | Double linked list |
| Ctiny_dlna::List< tiny_dlna::HttpHeaderLine * > | |
| Ctiny_dlna::List< tiny_dlna::HttpRequestHandlerLine * > | |
| Ctiny_dlna::List< tiny_dlna::HttpRequestRewrite * > | |
| Ctiny_dlna::List< WiFiClient > | |
| Ctiny_dlna::LoggerClass | Logger that writes messages dependent on the log level |
| Ctiny_dlna::MimeExtension | Mapping from file extensions to mime types |
| Ctiny_dlna::List< T >::Node | |
| Ctiny_dlna::QueueLockFree< T >::Node | |
| Ctiny_dlna::Notification | DLNA notification |
| ▼CPrint | |
| Ctiny_dlna::NullPrint | |
| Ctiny_dlna::StrPrint | |
| Ctiny_dlna::QueueLockFree< T > | A simple single producer, single consumer lock free queue |
| Ctiny_dlna::QueueLockFree< tiny_dlna::RequestData > | |
| Ctiny_dlna::RequestData | Provides information of the received UDP which consists of the (xml) data and the peer address and port |
| Ctiny_dlna::RingBuffer | Implementation of a Simple Circular Buffer. Instead of comparing the position of the read and write pointer in order to figure out if we still have characters available or space left to write we keep track of the actual length which is easier to follow |
| ▼Ctiny_dlna::Schedule | An individual Schedule (to send out UDP messages) |
| ▼Ctiny_dlna::MSearchReplyCP | Processing at control point to handle a MSearchReply from the device |
| Ctiny_dlna::NotifyReplyCP | |
| Ctiny_dlna::MSearchReplySchedule | Answer from device to MSearch request by sending a reply |
| Ctiny_dlna::MSearchSchedule | Send MSearch request |
| Ctiny_dlna::PostAliveSchedule | Send out PostAlive messages: Repeated every 5 seconds |
| Ctiny_dlna::PostByeSchedule | Send out ByeBye message |
| Ctiny_dlna::PostSubscribe | Send SUBSCRIBE message via UDP unicast |
| Ctiny_dlna::Scheduler | Scheduler which processes all due Schedules (to send out UDP replies) |
| Ctiny_dlna::StateValue | |
| Ctiny_dlna::StringRegistry | |
| ▼Ctiny_dlna::StrView | A simple wrapper to provide string functions on char*. If the underlying char* is a const we do not allow any updates; The ownership of the chr* must be managed externally! |
| Ctiny_dlna::Str | String implementation which keeps the data on the heap. We grow the allocated memory only if the copy source is not fitting |
| Ctiny_dlna::Url | URL parser which breaks a full url string up into its individual parts |
| Ctiny_dlna::Vector< T > | Vector implementation which provides the most important methods as defined by std::vector. This class it is quite handy to have and most of the times quite better then dealing with raw c arrays |
| Ctiny_dlna::Vector< char > | |
| Ctiny_dlna::Vector< const char * > | |
| Ctiny_dlna::Vector< HttpParameterEntry * > | |
| Ctiny_dlna::Vector< tiny_dlna::ActionRequest > | |
| Ctiny_dlna::Vector< tiny_dlna::Argument > | |
| Ctiny_dlna::Vector< tiny_dlna::DLNADevice > | |
| Ctiny_dlna::Vector< tiny_dlna::DLNAServiceInfo > | |
| Ctiny_dlna::Vector< tiny_dlna::Icon > | |
| Ctiny_dlna::Vector< tiny_dlna::QueueLockFree::Node > | |
| Ctiny_dlna::Vector< tiny_dlna::Schedule * > | |
| Ctiny_dlna::Vector< tiny_dlna::Str > | |
| Ctiny_dlna::XMLDeviceParser | Parses an DLNA device xml string to fill the DLNADevice data structure |
| Ctiny_dlna::XMLNode | Represents a single XML element |
| Ctiny_dlna::XMLPrinter | Functions to efficiently output XML. XML data contains a lot of redundancy so it is more memory efficient to generate the data instead of using a predefined XML document |
