Q) Will you support the 'Async' API / Paradigm?
A) No, because exactly what would you be doing?
Q) [But] You seem to support the theory of 'Cancellation'...
A) Methods which have the option can use it, `CancellationToken` was added to the .Net Framework to support `async`.
Q) You seem to utilize both the 'Begin' and plain old synchronous API in the code...
A) That was a statement but I will comment in rebuttal, the fact is that anyone can create a
ThreadPool implementation where there is not one and also implement a 'Begin' paradigm so long as
Thread support is available in the run time. I did this to experiment with the API and performance differences associated with each.
Q) What did you find in relation to the above?
A) What you would expect, you can only speed up things if the context switch associated with such is not slower than actually just doing the work in the first place. A good hack is to do a little of the work before the switch happens
if that is the only thing on the stack to do... Lastly, you can't really guarantee the time that a context switch will take especially under harsh conditions, you can only really make a worst case estimate; you combine this with garbage collection (depending
LatencyMode) and what you do think happens? (See Also), In short there is rarely a scenario where normal
sockets can be beaten by their asynchronous counterparts, they are usually only useful in reducing perceived latency at the cost of using more resources.
Q) What is a cool project I can use this for?
A) Creating RTSP Streams dynamically, you can then optionally repeat the
RTSP Streams over a IP -> XYZ
device or vice versa (XYZ device to
RTSP) to receive RTSP from a device on the other end. You can make your own home automation or data logging software which encompasses
RTSP functionality which allows you to incorporate it as your design requires.
RTSP is a good fit because it can be tunneled over
HTTP very easily thus allowing one to send data [for example a Remote Control to a receiver which repeats the data over
RTP and is consumed by a RTSP Server] to many consumers who can then act on the data received and optionally send data back to the host if required. You can also take
SDI, COAX or HDMI and repeat it over
LAN/WIFI connections in your home to simplify the wiring requirements or decrease cost to rent equipment from your cable provider. You can use any protocol and arrangement you want; One excellent example is the ability to use those adapters
with cheaper SDI cameras and then perform compression on the server as required. The server can be located in another continent all that would be required at the camera is that the connection attached to a
SDI cable and then attached to a SDI -> ETHERNET adapter which was then connected to the internet (WIFI can also optionally be used).
Q) Don't XYZ devices already implement
IP or RTSP?
A) They probably implement some portion of IP and possibly
RTSP. If you don't really need to use the RTSP function, you can create you own
Socket and listen and repeat the packets as necessary. Please also be aware that you can probably configure your router to multicast the traffic from a
XYZ receiver and then dynamically consume it as required wherever you can access the group endpoint. Please also be aware that some devices encapsulate the host protocol with some type of wrapping which should be detected and
most likely stripped if present.
Q) What are the file readers useful for?
A) Many things, you can stream a file over any protocol or stream which can be made available in the run time (interop) and at any frequency you can attain from the source media. HTTP(/2),
RTP, RTSP, IP, ETHERNET, etc.
Q) Will you implement more useful operations for file readers?
A) They are already useful, to convert files, to re-organize a
MP4, etc in the order required for smooth streaming... If you need more than that it depends, I have ambitions to do a lot. File writers would probably be next on the plate. It is possible I may get side tracked by additional formats or other
requirements though. The answer is Most Likely. (See Also)
Q) Can I fork your project?
A) No, you cannot really modify it either. Your lucky if your even allowed to be listed as a developer.
Q) Can I use it in commercial code?
A) Yes so long as you also remember to have a proper license file and link back to the project's home page. You may not modify the code but you can wrap it as necessary for your project such as deriving from it's classes and or
creating code which calls my classes, libraries and / or binaries.
Q) What about encoding and decoding?
A) See above, there is a lot to do and there is little to gain by doing it, especially video. Parsing for the bit streams would probably be more useful, some splicing tools etc.