lightalex: я б принимал данные в буфер и парсил уже его.
1) как только в сокете появляются данные -> читаем в буфер
2) после каждого чтения проверяем, не сформировался ли в буфере полный HTTP заголовок
3) как только наберется заголовок, парсим и выкусываем его
4) аналогично по частям ждём, собираем и парсим JSON
5) повторяем всё с начала - ждём новый HTTP заголовок и так далее
lightalex: ну вообще он сказал, что закроет соединение после передачи (Connection: close), потому content-length не обязателен (принимать всё до закрытия сокета). Возможно, у вас не просто по таймауту вылетает, а сокет давно закрыт, но программа ждёт данных? Проверьте в том же Wireshark, закрывается ли соединение сразу после передачи JSON. Если да, то усилия напрасны.
в случае keep-alive соединений без content-length никак (чтоб разделить порции данных).
Не используйте transfer_all, вручную обрабатывайте весь входящий поток. например, заголовок HTTP запроса имеет явные начало и конец, в заголовке же указывается точный размер тела запроса. уже из этого вы точно можете определить, когда следует прекращать приём данных. Когда я писал взаимодействие по HTTP, сложным моментом была организация собственного буфера данных, когда принимается больше одного запроса, и первый нужно обрабоать немедленно, а другой поставить в очередь на дозагрузку и обработку. Вам это тоже придётся учитывать.
Wasya UK: какой вид для вас является нормальным? К сожалению, с веб языками я не знаком.
Предположу, что вам требуется
metadata.picture[0].data.toString('base64');
sdxq: если железо почти идентичное, то может и включится. 6575 очень медленный и старый проц. Я бы порекомендовал не морочить голову ремонтом и купить какой-нибудь Oukitel C5 за $50. Гораздо мощнее будет.
Алексей Гриченко: может и там. весь код очень странно выглядит. несколько лет назад компилятор бы вообще не позволил выделить память таким способом. разбаловали программистов :)
Алексей Майрин: Например в случае 4-битного изображения сразу за заголовком BMP файла будет находиться таблица цветов с 16 значениями (на каждый возможный вариант 4-битного значения пикселя) по 4 байта (00RRGGBB), задающая цвета картинки. Эта таблица будет задавать то, как именно будут отображаться пиксели. Стандартный вариант - цвета 00000000, 00111111, 00222222 ... 00FFFFFF. Тем самым пиксель со значением 0 будет преобразован в черный цвет (00000000), а пиксель со значением F будет белым (00FFFFFF). Если в таблице обратить порядок значений, получится инверсия цветов. Таблица часто делается нестандартной для наименьших потерь цвета за счет уменьшения битности.
если у вас есть альфа канал (и наложение картинок друг на друга), придется его учитывать и смешивать цвета нужным образом.
1) как только в сокете появляются данные -> читаем в буфер
2) после каждого чтения проверяем, не сформировался ли в буфере полный HTTP заголовок
3) как только наберется заголовок, парсим и выкусываем его
4) аналогично по частям ждём, собираем и парсим JSON
5) повторяем всё с начала - ждём новый HTTP заголовок и так далее
примерно таким образом я делал)