Как взаимодействовать с txt файлом, находящимся на сервере, с помощью с++?

Question

[StopaPopa228]

Есть сервер, на нем находится некий txt файл, допустим в нем содержится некоторая информация, которую мы должны будем выгружать при каждом закуске программы, как это можно реализовать при помощи С++?

Answer 1

[rPman]

Вопросов тьма, от ответов на них зависит и результат
Например - сервер доступен ли по какому то протоколу?
во всех операционных системах можно настроить какой-нибудь протокол smb/nfs/ftp/http/ssh/... все они позволяют получить доступ к файлу так или иначе.
Это вопрос не программирования а devops, настроить соответствующее приложение-сервер, на стороне клиента есть очень универсальная библиотека - libcurl (и одноименная утилита) умеет наверное все популярные и не очень протоколы.

Само собой можно написать свой сервер по своим правилам (гуглить socket server c++) но стоит ли?

p.s. netcat, консольная утилита, позволяет отправить через пайпы содержимое файла в сетевой сокет а на другой стороне соответственно наоборот принять, способ тупой, простой, на основе его и баш можно сделать однострочник сервер для отправки файла любому подключившемуся.

Comments

[HighMan]

Вообще, не понятно, на хрена это реализовывать на СРР.
В разы быстрее нарисовать скрипт на python или даже bash.
А если учитывать, что файл текстовой, что следует из расширения, то работать с ним на С или даже СРР - жуткий мазохизм.
Хуже с текстом работает, разве что, assembler.

[rPman]

HighMan, я не знаю что там у автора, скорее всего ему ради образовательных целей.

Но из моего опыта, переход с php (с ним сравним по скорости из интерпретируемых языков только javascript, с оговорками, да, если писать под .net или java виртуальные машины или к примеру go, то будет быстрее, но это языки уровня c++) дал ускорение в обработке текстовых json в 10 раз, а так как текстовых данных в упакованном виде у меня порядка 6 терабайт, ускорение считаю значимым, притом что писать в низкоуровневом стиле не пришлось.

[HighMan]

rPman, я ооочень давно забил на PHP. Во первых меня мутит от вебдизайна - не мое.
Во вторых он пригоден для повседневных задачь с оговорками.
На моей позапрошлой работе кучу всякого системного хлама реализовывали на PHP. Ну а чо? Язык быстрый, не чета Python и bash.
Все было замечательно пока... Пока не начались гигантские утечки памяти в приложениях, которрые крутятся долго.
Скорость пыхи обусловлена тем, что она не заморачивается "сбором мусора". И это риводит к весьма печальным последствиям. Память лишь выделяется и ни как не высвобождается. Это не напрягает когда скрипт вызывается на веб сервере. Скрипт вызван, он отработал и умер. Систем сама высвободила память. Если же скрипт должен работать долго, то кирдык. Он сожрет всю память.
Что же кается C, C++ то я их очень люблю. Как бы, с них я и начинал тернистый путь IT. Но чем дальше, тем реже я их использую :( С текстовыми данными работать мучение, а уж если озаботится поддежкой UTF-8, то ну на хрен!

[rPman]

HighMan, какая версия php у вас была
сам php в утечках памяти не может быть виновен, как и везде, все зависит от разработчика

[HighMan]

rPman, php 7.3 вроде.
PHP не виновен в утечках памяти. В нем, попросту, не предусмотрен такой механизм, что и позволяет ему крыть по скорости Python.
PHP умеет ТОЛЬКО выделять память, но не высвобождать ее. Нет сборщика мусора и нет изголений по обеспечению его работы.
Это не баг. Это фича!
PHP изначально разрабатывался для работы с HTTP сервером.
Т.е. скрипт запускается, выполняет какие-то действия и умирает. Пофиг на то, что он не высвобождал память. После смерти за ним приберется система.

[rPman]

читаю тебя и не понимаю, контроль над объектами, циклические зависимости, все это было еще в 5.4

если переменной присвоить другое значение и на прежнее значение больше никто не ссылается, память освобождается, проверено неоднократно.

Answer 2

[12rbah]

можно написать tcp или http сервер, который будет отдавать этот файл клиенту.

Comments

[StopaPopa228]

возможно я что-то не понял, но сервер уже есть, просто надо открыть txt, который на нем уже есть

[12rbah]

StopaPopa228, кроме самого сервера, нужна программа которая сможет передавать этот файл по сети например ftp-сервер, на стороне пользователя нужен будет ftp-клиент, который умеет обращаться к ftp-серверу.

Answer 3

[mayton2019]

Нужен http-client.

Вот как тут пишут https://stackoverflow.com/questions/822581/what-c-...

Comments

[Roman K]

Нужен http-client.

Это преступная формулировка, которая сформирует у человека шаблонное мышление. http-client не нужен (кстати почему только клиент?), http можно использовать, но это вовсе необязательно. Можно настроить rsync, можно открыть tcp соединение, можно сделать свой протокол поверх tcp (это часто может быть удобней), можно даже кидаться udp датаграммами, можно установить quic или kcp поверх udp. Вариантов миллион.

[mayton2019]

Roman Kitaev, вот тебе бабушка и Юрьев день.

Оказывается если сишнику надо куда-то скачать файл - то он берет что угодно но не http-взаимодействие.
Я так понимаю что должен быть какой-то пинок под зад или шенкель чтоб понять что наличие протокола
всяко лучше чем сырой сокет. Или вы - мозохисты?

P.S. А если 2 файла будет?

[shurshur]

Roman Kitaev, ещё можно публиковать файл в TXT-записи DNS :)

[Roman K]

mayton2019, я не придираюсь к методу, я придираюсь к формулировке

[jcmvbkbc]

наличие протокола всяко лучше

mayton2019, наличие протокола -- всяко лучше, но почему это должен быть HTTP?

P.S. А если 2 файла будет?

А если каталог надо будет прочитать?

[mayton2019]

jcmvbkbc, погоди. Придержи коней :)

Answer 4

[Владимир Коротенко]

пусть это будет самба
https://learn.microsoft.com/en-us/windows/win32/fi...

Comments

[mayton2019]

Шутки ради можно было предложить gopher.

[Владимир Коротенко]

mayton2019, хорошая шутка с учетом того что эта функция пережует и этот протокол.
по идее она обрабатывает все распознанные протоколы:
* file
* smb
* http
* ftp
* gopher
* какую либо дичь зарегистрированную в обработчиках unc

[mayton2019]

Владимир Коротенко, trivial-ftp еще есть. На нем PXE-загрузка обычно работает. Или обновление прошивок некоторых железяк. Тоже можно было посоветовать. И это поверх Udp.

Ну куда уж проще :)