Is there away for server (web-server of web-page or file server) to know what bandwidth client had during last access or during page/file request? Can this information be sent via cookie or together with page/file request?
I guess this is more of theoretical question, since I want to know if server can provide lower resolution image for clients with bad bandwidth available to them.
Yes; use JavaScript Image onload event to time the download speed of a small image (like a logo), then do something usefull with the result like downloaded a large image if the client has the bandwidth.
Related
I am working on a network related project, where communication between client and server is implemented by grpc-cpp. I want to estimate the bandwidth/throughput of data transfer between server and client. Currently, client sends request containing data and server will reply a short message. The data is transferred as bytes with size 10~100KB.
It can be easy to estimate the bandwidth on client side by measuring the time difference between sending and receiving, then minus the execution time on server. But how to do that on server side? It looks like the GlobalCallbacks::PreSynchronousRequest is called only after the whole frame has been received, and there is no way to know the duration between two packets (each contains a part of the whole frame).
Is there any other way to roughly estimate the bandwidth between server-client on server side?
Depending on what you want to achieve with this bandwidth measurement, tools can vary but I suggest to start with a network throughput measuring tool such as iptraf, iftop, so on. Then you don't need to implement this by yourself with the limitation of gRPC API which isn't meant to measure this bandwidth.
currently working on a youtube video downloader . using youtube-dl,Django and hosting my project on Pythonanywhere,i almost completed my project but when i send request more then 15-20 youtube block my pythonanywhere server ip. SO i want to ask that how can i solve this blocking problem. free proxies takes too much time to respond. please give me a solution.thanks in advance
I suspect that most YouTube downloaders do one of three things:
Execute client side code to do the actual download. Instead, what the server/extension does is go through the code to find a file being served.
Pay for professional proxy servers sufficient to handle the number of downloads one seeks to make without running into rate limits. Proxies are not expensive.
Limit the rate at which downloads are conducted.
Those are the only ways I can see around the blocking problem. Youtube really doesn't want you to do what you are trying to do and has put a lot of thought into stopping it.
I have been developing server side applications in java, and now I have been asked to serve some mobile applications. The question always bugs me over "how much" data should I send to the app ?
If I have to transfer a large xml document, should I send it node by node, as per requirement....if yes, wont it consume the phone battery more (as the phone will be creating new connections for all the nodes). If I decide to send the whole document at once, it may take a long time for the client to download the whole doc, and may have problem temporarily storing it...even more, there may arise data inconsistency in the two copies of data. In short, I need to know "is the creation of connection for a mobile device, too expensive ?" Which approach is better - receive data in chunks, by creating multiple connections OR receive all data together in one connection.
I also need to know, while developing my web service for the mobile clients, should I send them the image URI or the image data (as byte array) ?
Thanks.
You should download as few (times) as possible.
It´s the application that will answer your question. Don´t download lists of 1000 items, load just 10, wait the user scroll down, load next 10. cache the items.
A bit more tricky way to do soemthing like that is registering the user, that is downloading data, on the begining, he first time uses the app, it will download as many stuff as you need, call it the first time loading. Register, what the user downloaded. The next call from the user u send him only data that was changed, and send with this data the changeactions to perform on the clients device.
With mobile clients, the latency kills more than the data package size. While you should not send more data than you are going to consume, node by node is not a good method to employ. This is not as much a battery answer as a user experience answer.
The best way to architect for mobile is find the right bite size for the meal. In other words, you don't send 10,000 records at one time, but you don't send a grid of 10 items 1 row at a time.
Depending on image size, you should send the image directly (base64 encoding is common) and not as a link. An exception would be sending the user to a web page and letting them browse, but then it is not really a "mobile application" any more, right?
So we have some server with some address port and ip. we are developing that server so we can implement on it what ever we need for help. What are standard/best practices for data transfer speed management between C++ windows client app and server (C++)?
My main point is in how to get how much data can be uploaded/downloaded from/to client via his low speed network to my relatively super fast server. (I need it for set up of his live stream Audio/Video bit rate)
My try on explaining number 3.
We do not care how fast is our server. It is always faster than needed. We care about client tyring to stream out to our server his media. he streams encoded (via ffmpeg) live video data to our server. But he has say ADSL with 500kb/s of outgoing traffic. Also he uses some ICQ or what so ever so he has less than 500 kb/s per second. And he wants to stream live video! So we need to set up our ffmpeg to encode video with respect to the bit rate user can provide. We develop server side and client side. We need a way of finding out how much user can upload per second currently (so value can change dynamically over time)
Check this CodeProject Article
it's dot-net but you can try figure out the technique from there.
I found what I wanted. "thrulay, network capacity tester" A C++ code library for Available bandwidth tracking in real time on clients. And there is "Spruce" and it is also oss. It is made using some of linux code but I use Boost library so it will be easy to rewrite.
Offtop: I want to report that there is some group of people on SO down voting on all questions on this topic - I do not know why they are so angry but they deffenetly exist.
Is it possible to POST request data from browser to server in compressed format?
If yes, How can we do that?
Compressing data sent from the browser to the server is not natively supported in the browsers.
You'll have to find a workaround, using a clientside language (maybe a JavaScript GZip implementation, or a Java Applet, or ...). Be sure to visually display to the user what the browser is doing and why it is taking some time.
I don't know the scope of your application, but on company websites you could just restrict input to compressed files. Ask your users to upload .zip/.7z/.rar/... files.
The server->client responses can be gzip compressed automagically by the server.
Compressing the client->server messages is not standard, so will require some work by you. Take your very large POST data and compress it client-side, using JavaScript. Then decompress it manually on the server side.
This will usually not be a beneficial thing to do unless your bandwidth usage is a major bottleneck. Compression requires both time and CPU usage to perform.