Here is my scenario:
User speaks continuously to a microphone on client side, and the client code need post the recorded audio data to server chunk by chunk, though HTTP protocol.
Server side can receive and process the audio data chunk by chunk.
The question is about the code on client side.
Previously using dotnet framework I can implement the posting as stream (chunks) with below code:
https://learn.microsoft.com/en-us/dotnet/api/system.net.httpwebrequest.sendchunked?view=netframework-4.8#examples
But it doesn't work after switching to dotnet core, which is a known issue mentioned here:
https://github.com/dotnet/runtime/issues/18632#issuecomment-470611032
I saw httpclient was recommended by above thread.
But I didn't find out any sample code for my scenario using httpclient.
For my scenario I need get connected to the server, and then get an input stream based on this connection, and then write my recorded audio from microphone to server chunk by chunk through this stream.
This can be done by using the sample code in above link.
How should I write the code to implement the same effect using httpclient?
Related
I would want to send a message from the server actively, such as using UDP/TCPIP to a client using an arduino. It is known that this is possible if the user has port forward the specific port to the device on local network. However I wouldn't want to have the user to port forward manually, perhaps using another protocol, will this be possible?
1 Arduino Side
I think the closest you can get to this is opening a connection to the server from the arduino, then use available to wait for the server to stream some data to the arduino. Your code will be polling the open connection, but you are avoiding all the back and forth communications to open and close the connection, passing headers back and forth etc.
2 Server Side
This means the bulk of the work will be on the server side, where you will need to manage open connections so you can instantly write to them when a user triggers some event which requires a message to be pushed to the arduino. How to do this varies a bit depending on what type of server application you are running.
2.1 Node.js "walk-through" of main issues
In Node.js for example, you can res.write() on a connection, without closing it - this should give a similar effect as having an open serial connection to the arduino. That leaves you with the issue of managing the connection - should the server periodically check a database for messages for the arduino? That simply removes one link from the arduino -> server -> database polling link, so we should be able to do better.
We can attach a function triggered by the event of a message being added to the database. Node-orm2 is a database Object Relational Model driver for node.js, and it offers hooks such as afterSave and afterCreate which you can utilize for this type of thing. Depending on your application, you may be better off not using a database at all and simply using javascript objects.
The only remaining issue then, is: once the hook is activated, how do we get the correct connection into scope so we can write to it? Well you can save all the relevant data you have on the request to some global data structure, maybe a dictionary with an arduino ID as index, and in the triggered function you fetch all the data, i.e. the request context and you write to it!
See this blog post for a great example, including node.js code which manages open connections, closing them properly and clearing from memory on timeout etc.
3 Conclusion
I haven't tested this myself - but I plan to since I already have an existing application using arduino and node.js which is currently implemented using normal polling. Hopefully I will get around to it soon and return here with results.
Typically in long-polling (from what I've read) the connection is closed once data is sent back to the client (arduino), although I don't see why this would be necessary. I plan to try keeping the same connection open for multiple messages, only closing after a fixed time interval to re-establish the connection - and I hope to set this interval fairly high, 5-15 minutes maybe.
We use Pubnub to send notifications to a client web browser so a user can know immediately when they have received a "message" and stuff like that. It works great.
This seems to have the same constraints that you are looking at: No static IP, no port forwarding. User can theoretically just plug the thing in...
It looks like Pubnub has an Arduino library:
https://github.com/pubnub/arduino
I'm writing an app which uses persistent connections over http - that is, the web server never "finishes" writing to the response stream, and the client app reads data from the response stream as it comes in.
I wrote some .NET 3.5 desktop/winforms apps to confirm that the server & client code works, and then wrote a windows phone app to do the same thing. The only difference between the desktop/phone code was that I set the AllowReadStreamBuffering property to false on the phone.
The phone app worked last night, but today it does not work - when attempting to read the response stream, it hangs until the connection is closed from the server side - which means that the AllowReadStreamBuffering setting is not being honored by HttpWebRequest.
The difference between last night and now is that last night, I was on wifi, whereas today i'm connected over cellular.
My hypothesis is that on the phone, HttpWebRequest only honors AllowReadStreamBuffering = false when the connection is wifi (and perhaps Ethernet), but that it ignores it and buffers when using the cellular network.
So is it true that HttpWebRequest forces read stream buffering when connected over cellular? I haven't been able to find any documentation that confirms this behavior, so I'm wondering if anybody else has experienced this. I'll be able to test this more thoroughly later, but for now I figured i'd ask the question.
UPDATE 5-11-12
Tested and answered my own question (see below)
AllowReadStreamBuffering = false is honored on cellular connections; otherwise (for example) audio streaming apps wouldn't function properly.
I verified that my WP7 app would not initially read the response stream unbuffered when connected via cellular - it only does so when on ethernet or wifi.
So I modified my server httphandler to write an initial chunk of data (8k) to the response stream, at the beginning of the connection. Doing this made the app read the response stream immediately on cellular, just like it did when it was on wifi. After ignoring the initial blast of data, the app processed the individual bytes just fine, and in real-time.
The only conclusion that I can think of is that when connected over cellular, HttpWebRequest initially requires a small amount of data to be buffered before allowing the stream to be read unbuffered.
I've been studying the APE (Ajax Push Engine - http://www.ape-project.org/) for several weeks, and I have read all the documentation they have at the website.
The APE project claims "real-time data streaming", but I just cannot find a good example for that. I'm kind of frustrated with their documentation.
The possible wikipage I read at their website:
http://www.ape-project.org/wiki/index.php/Tutorial:How_to_write_an_application_with_APE
But again, it just has some concepts, not detailed info.
After doing some Google search, I started feeling more frustrated. No valuable tutorials or examples for my purpose.
So I'm posting this here.
Basically, what I've been wanting to do is, an HTTP streaming server (with very computation expensive) can still scale reasonably well (100 or 200 clients). Requirements:
Use HTTP protocol (no RTMP);
The client streams the audio data to the server;
The server receives the audio data, processes it and sends the result back to the cient WHILE receiving the audio data from the
client;
The processing of the audio data is done in a C/C++ library;
The server is also be able to stream several-second audio data to the client, and the client can play the audio WHILE receiving the
audio data from the server;
A long-lived connection/session should be made between a client and the server, and the disconnection (TimeOut or UserDisconnect)
should be detected by the server;
My questions are:
What APE examples and tutorials should I read to facilitate my needs?
Where can I find a good example using APE HTTP Streaming?
How can I create a very simple HTTP streaming example (server streams)?
How can I hook up my computation-expensive C/C++ lib at the server side?
How can I maintain the state of each client connection/session at the server side?
If anyone know any idea of my requirements or questions, please let me know.
Thanks.
Peter
APE is meant for exchanging JSON data - not streamed data.
So, you must find a solution where your standard web server (running your lib) receives and parses the data.
What you can do with APE then is so called "inline push". This means, sending data from the backend server to the APE server so it can forward the data to the clients.
In your case, I would regularily have the parsing lib send a status update to the APE server so it can be distributed to the client.
Regarding your questions:
http://www.ape-project.org/wiki/index.php/Libape-controller
Nowhere - it is not meant for that
With anothother server side programming language of your choice
Obviously, depends on your Apache/Nginx and server language
Thats something APE can and will do - if you do the required programming on the server side. You already commented on my blog, so you might have seen http://www.xosofox.de/2010/10/ape-user-handling/ - this should give you some hints.
tl;dr
Use another server as backend for the lib
Have the lib server send short status updates via inline push to APE so APE will push it to
the client
A simple problem. I have an ASHX handler which generates a report. Unfortunately, this process can take 2 or more minutes to finish and Azure will close the connection before this handler can respond. Why? Because the connection is idle for too long, thus it is killed off.
So, I need to keep this connection alive in some way. To make it a bit more complex, the handler is called from a Silverlight application which will call the handler from a frame on the current webpage or (when not running from a browser) create a new browser instance to call the handler.
My challenge is to get around this timeout with a minimum amount of code. But also, the code needs to work exactly as it does now!
Opening the handler in a separate frame or browser window allows the report to be saved anywhere on the system of the user. If I would download it from within the Silverlight code, I will not have proper write access. There will be no permission given to any Silverlight application that needs to write to the local disk, thus the work-around with the browser/frame.
Not too sure about HTTP transport, but you can certainly use TCP keep-alives at the socket level. However, then you need to create socket listener to download HTTP content (way overkill).
Perhaps there is a much simpler solution? Why don't you have the client make the request to generate the report and have the handler return a SAS signature (time limited, read-only signature) to where the report will eventually be put in blob storage. This is very quick and requires no open TCP connection. The report generator should simply create the report in a file to be downloaded at the blob location it sent to the client (any GUID would work here) instead of streaming it back over the response. Finally, the client just needs to poll the location until it gets a file. Now you are nice and asynchronous with short open connections and don't have to worry about this TCP timeout issue. The code to do this is far, far less complex than anything to work around a TCP timeout.
I'm trying to write a small program that I can talk to Omegle strangers via command line for school. However I'm having some issues, I'm sure I could solve the problem if I could view the headers sent however if you talk to a stranger on Omegle while Live HTTP Headers (or a similar plug-in or program) is running the headers don't show. Why is this? Are they not sending HTTP headers and using a different protocol instead?
I'm really lost with this, any ideas?
I had success in writing a command line Omegle chat client. However it is hardcoded in C for POSIX and curses.
I'm not sure what exactly your problem is, maybe it's just something with your method of reverse engineering Omegle's protocol. If you want to make a chat client, use a network packet analyzer such as Wireshark (or if you're on a POSIX system I recommend tcpdump), study exactly what data is sent and received during a chat session and have your program emulate what the default web client is doing. Another option is to de-compile/reverse engineer the default web client itself, which would be a more thorough method but more complicated.