Новое сообщение в форум Сети, сокеты, протоколы

Форум	Сети, сокеты, протоколы
Тема	Как правильно задавать вопросы

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Sharov, Вы писали:

S>>1)Допустим имеется клиент. Пусть имеется api, когда клиент что-то заращивает у сервера http get(большой json объект с 10000 записей). Правильно ли я понимаю, что   в данном случае у меня http собирает данные (копит в буфере), и когда все данные будут доступны (в памяти), мой клиент получит [b]один[/b] обычный http get ответ?

N>Нет, зависит от того, как работает генератор ответа.
N>В HTTP/1.1 и последующих есть chunked encoding, позволяющее отдавать ответ по частям - и клиент может его обрабатывать по частям по мере получения. Но можно и цельным телом. Это уже как серверу удобно. Оба варианта должны поддерживаться полноценными клиентами.

S>>2)Допустим имеется сервер, который получает огромный (8гб) файл от клиента. Вот у меня в api есть stream параметр (networkstream в случае дотнет). Верно, что в данном случае мой сервер получит http post, хотя его тело (т.е. 8гб), еще до конца не получено? Т.е. я получю [b]один[/b] http post и начинаю читать содержимое, которое до конца-то может и не придти, т.е. получается что http post в данном случае может не знать свой размер.

N>Точно так же, можно chunked. Но тут уже вопрос дизайна повыше HTTP. Если отправляется 8GB, вероятность разрыва огромна - значит, у клиента должен быть какой-то аплоадер (скрипт в браузере или аналог), который вызывает команду отправки по частям, и закончив отправку - говорит "фиксируй и сохраняй на постоянное".
N>Как это будет в вашем API - не знаю, не видел. Может, оно и попытается одним куском выслать.

S>>Т.е. я понимаю разницу между буферизацией  и потоком, но я не понимаю как 2) случае все это будет [b]физически[/b] оформлено в [b]один[/b] http post.

N>Оформить-то можно, но удобно ли.

S>>3)Про физику процесса -- я правильно понимаю, что у меня данные копятся в буфере http, а tcp просто прокидывает chunk'и данных? И когда у меня данные закончились - все пришло, либо разрыв - то tcp манифистирует об этом http, и уже http либо оформляет стандартный запрос\ответ, либо у меня вылезает ошибка о разрыве (но в этом случае это не ошибка http, а tcp socket что-то там).

N>Для HTTP настоятельно рекомендуется или Content-Length заранее, или chunked encoding. Тогда при обрыве TCP принимающая сторона поймёт, что данные неполные.
N>Можно отправлять и без этого, разрешается, но не рекомендуется - опасно.
N>Ошибку по самому TCP можете и не увидеть, если программа, например, упала с той стороны - в этом случае просто сокет закрывается (да, увы, такой дизайн - многие на него жалуются).

S>>И когда у меня данные закончились - все пришло, либо разрыв - то tcp манифистирует об этом http

N>В общем случае следует считать, что TCP не скажет, что был разрыв. Он может, но не гарантируется. Проверяйте таки по длине или финальному чанку.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail