книги по сетевому программированию
Стивенс. Это, правда, для C, зато системные вызовы.
я бы посоветовал вначале разобраться с многопоточным программированием, если эта тема конечно не знакома, и только потом переходить к сетям.
с чего бы вдруг?
с того, что написать простейший tcp сервер намного проще, если у тебя есть несколько отдельных потоков.
с чего бы это?
С того, что новичок первым делом нагуглит пример с блокирующими (которые по дефолту получаются и в винде и в *nix) сокетами и блокирующими вызовами recv/accept. С select разбираться чуть сложнее, это следующий шаг после простейшего приложения. И будет человек переводить сокеты в неблокирующий режим и изобретать велосипед с педалями в виде цикла опроса сокетов из одного треда и кусочного выполнения задач обработки данных, вместо того чтобы воспользоваться многозадачностью. Это конечно не плохо, но начинать с этого, имхо, не надо.
ну как бы простейший сервер может просто посылать данные ничего не читая - в этом случае не понабиится почти наверняка ни select-ов ни неблокирующих write-ов
а начинать писать tcp сервер без select-а это не тру
а начинать писать tcp сервер без select-а это не тру
а как же неблокирующий accept? или простейший tcp-сервер может обслуживать не больше 1 клиента?
ты не понял
речь была про следующее
для простейшего сервера, работающего на loopback-е этого более чем достаточно
если же у тебя соединения будут приходить быстрее, чем ты можешь в них послать 13 байт, то многопоточность тебя не сильно спасет )
речь была про следующее
while(true) {
fd = accept;
write(fd, "hello world!\n");
close(fd);
}
для простейшего сервера, работающего на loopback-е этого более чем достаточно
если же у тебя соединения будут приходить быстрее, чем ты можешь в них послать 13 байт, то многопоточность тебя не сильно спасет )
ок, и что дальше делать с таким сервером?
а "дальше" уже в любом случае речь пойдет о select-e и треды не то чтобы очень нужны
если же у тебя соединения будут приходить быстрее, чем ты можешь в них послать 13 байт, то многопоточность тебя не сильно спасет )Она как раз тебя и спасёт.
все равно, писать сетевые приложения в один поток и не пользоваться наличием возможности параллельно выполнять разные задачи - это костылизм, может еще и компилятором не пользоваться, ведь можно в хекс коды фигачить, на крайняк на асме.
ну это если конечно речь не идет о написании для 10-100к подключений, там конечно идея "одно подключение" - "один (2, 3 ...) поток" терпит былинный отказ.
ну это если конечно речь не идет о написании для 10-100к подключений, там конечно идея "одно подключение" - "один (2, 3 ...) поток" терпит былинный отказ.
для того, чтобы сделать один поток на соединение, не нужно именно _разбираться_ в многопоточном программировании - надо взять шаблон и вставить туда свой "hello, world"
а если задача сложнее, то там уже более интересные вещи начнутся, в которых нужно разбираться: типа что будет, если несколько потоков одновременно делают операции с сокетом - и это очень системно-зависимо
а если задача сложнее, то там уже более интересные вещи начнутся, в которых нужно разбираться: типа что будет, если несколько потоков одновременно делают операции с сокетом - и это очень системно-зависимо
а что никто не предлагает фреймворк взять какой-то?
самое банальное - веб-сервер
ну и для клиента какую-нибудь библиотеку
самое банальное - веб-сервер
ну и для клиента какую-нибудь библиотеку
согласен с первой частью, но по-крайней мере запустить поток и понимать что 2 потока работают параллельно нужно уметь.
или простейший tcp-сервер может обслуживать не больше 1 клиента?А зачем ему? Форкнулся, обслужил, умер.
Она как раз тебя и спасёт.А чем поможет многопоточность, если приходит очень много коннектов? accept все равно однопоточный будет, а отдавать другому потоку сделать send и close - больше пользы, чем вреда?
Хотя... accept же можно параллельно из нескольких потоков вызвать? Вроде не запрещено. Но я такого пока не видел. Хотя кажется, что и от такого немного пользы.
много коннектов которые однажды установлены и живут долгое время и много коннектов, которые живут доли секунды и случаются много раз в секунду это разные вещи. в первом случае accept из одного треда вполне ок, а обслуживание - пулом тредов. во втором случае кажется таки можно и accept внесколько потоков раскидывать.
еще можно в одном треде читать сокет, а в другом - писать в него.
еще можно в одном треде читать сокет, а в другом - писать в него.
лучше же вначале понять как оно на низком уровне работает, а во фреймворке это хорошо спрятано за абстракциями и в результате разобравшись с одним фреймворком можно так и не понять как же это работает на самом деле.
А зачем ему? Форкнулся, обслужил, умер.форк - это тоже многопоточность, вернее многопроцессность. и годится только пока коннекшны не взаимодейтвуют друг с другом. попробуй например сервер для чятика написать на форкающемся сервере, сообщения будешь через пайпы гонять или через юникс сокеты или через хитровыебанную шареную память опять же с мьютексом, вместо того чтобы в обычной памяти через мьютекс разделять.
Хотя... accept же можно параллельно из нескольких потоков вызвать? Вроде не запрещено. Но я такого пока не видел. Хотя кажется, что и от такого немного пользы.Можно. И ещё можно это делать асинхронно.
Ситуацию, когда один поток не справляется с accept и выкидыванием задачи в тред пул, очень просто воспроизвести. Это не такая уж большая нагрузка на самом деле, особенно если программируешь не на C.
попробуй например сервер для чятика написать на форкающемся сервереТы же сначала про простейший tcp-сервер писал там, где я откомментил. А теперь начинаешь усложнять примеры.
ок, согласен, для простейшего сервера форка достаточно, но это не отменяет того, что такой сервер не является однопоточным, т.е. даже для простейшего сервера нужно больше одного потока, хоть fork, хоть pthread_create
Оставить комментарий
xoki87
я в этом нифига не смыслю, с чего лучше начинать изучение написание сетевых приложений? язык c++