То есть на стороне клиента определяется длина, отсылается серверу, а затем уже отсылается сам сериализованный объект сообщения, так?

https://blog.stephencleary.com/2009/04/tcpip-net-sockets-faq.html Вот тут все про всег грабли рассказано. Про длинну сообщения перед ним, вот пример: https://blog.stephencleary.com/2009/04/sample-code-length-prefix-message.html Т.е. ты посылаешь сначала int(4 байта) с количеством байт в сообщении. А потом само сообщение. Принимающая сторона читает 4 байта, выясняет сколько байт в сообщении. И считывает его.

Кстати, а чем не подходит такой вариант: int l; do { l = s.Receive(buffer); textBox1.Text += System.Text.Encoding.ASCII.GetString(buffer, 0, l); } while (l > 0);

Ну это вот примерно и есть вариант с передачей длины в начале.

только всё под капотом

тоже так принимаю, полёт нормальный

Ну это вот примерно и есть вариант с передачей длины в начале.

Так здесь же не передаётся длина, здесь мы просто читаем до конца, пока есть что читать, насколько я понимаю.

Ну по хорошему надо не просто int в поток выплёвывать, а через NetworkToHostOrder. И также считывать.

Как програмно (WPF) посмотреть занят ли файл другим процессом?

Как програмно (WPF) посмотреть занят ли файл другим процессом?

только через try catch

Так здесь же не передаётся длина, здесь мы просто читаем до конца, пока есть что читать, насколько я понимаю.

А. Ну да. Кстати Receive поток блокирует.

Ну, это однопоточный пример. Есть же и RecieveAsync. Но вообще такая концепция с циклом и чтением пока не 0 нормальная?

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

Точнее там такое условие: while (s.Available > 0);

А почему?

Ну допустим у тебя будет два типо сообщений от клиента серверу. один - сообщение пользователя другой - какая-то служебная информация, которую не надо показывать пользователю. Тебе нужно будет что-то вроде протокола сообщений. А как ты их потом бить собираешься? также считывать, переводить в текст, а потом искать по тексту где сообщения заканчиваются? Код быстро в какашку превратится

Я собирался передавать сериализованные в байты объекты сообщений. А потом их десериализовывать обратно в объекты на принимающей стороне...

дело в том, что у тебяв программе может быть не один тип ссобщений, а несколько. И чтобы понимать, куда именно надо направить пакет от клиента, надо передавать какую-то дополнительную информацию

я использую примерно такую схему для каждого пакета

Да пожалуйста - в объекте Message можно сделать поле message_type, в котором указывать тип сообщения, а принимающая сторона после получения объекта поймет, что делать. Разве плохо?

Ну допустим длина одного сообщения 100 байт. Второго получилась 150 байт.

Считал ты 250 байт

как делить будешь

не плохо и не хорошо, это твоя реализация, продумай что ты хочешь полностью)

как делить будешь

Хм :/

а ещё можешь подумать, как будешь отличать пакет-ответ с сервера, и пакет-ивент =)

Да отличать то ладно, я вот над разделением думаю...

чего именно?

как делить будешь

Да вот

(4 байта на длину сообщения)(2 байта на тип сообщения)(данные)

как делить будешь

никак

сериализовать в жсон и гнать пачки

и читать до конца

жосн не оптимально ддля тсп =) уж лучше протобаф

+

но для учебного проекта пойдет

Ну смотрите, сериализовал я объект в байты, отправил их серверу, он считал их до конца, какие тут проблемы с разделением?

данне склеиваются в тсп и слипаются как им угодно

гарантируется только доставка и порядок

в юнити надо выбрать

Колясочник.. мельчает линуксоид

Ну, поток байт, который я отправил не изменится же. Десериализую в объект и всё... Какие проблемы?

А можно где-нибудь почитать про делегаты и лямбды языком для дебилов?

Типа на примере паровозиков или чего-то такого

Я просто тестил обмен текстом, у меня получение было при помощи цикла, который я выше приводил, всё приходило, я декодировал текст и готово. Почему я не могу вместо декодирования текста поставить десериализацию и получить свой объект?

Я просто тестил обмен текстом, у меня получение было при помощи цикла, который я выше приводил, всё приходило, я декодировал текст и готово. Почему я не могу вместо декодирования текста поставить десериализацию и получить свой объект?

ты можешь отправить поток байт, а он придёт не целиком

ты можешь отправить поток байт, а он придёт не целиком

а следующиим чтением ты можешь получить конец первого объекта и начало второго, например

а следующиим чтением ты можешь получить конец первого объекта и начало второго, например

если tcp, то не может

да ладно

а если я пошлю объект в 2 гига ?

как ты его за одно чтение считаешь?

Объект в 2 гига

пример

Это даже не god object

Я просто тестил обмен текстом, у меня получение было при помощи цикла, который я выше приводил, всё приходило, я декодировал текст и готово. Почему я не могу вместо декодирования текста поставить десериализацию и получить свой объект?

если ты просто читаешь и выводишь текст, то тебе в самом деле всё равно, это как одно большое сообщение. А вот для того чтобы текст передавать на десериализацию в жсон конвертер тебе нужно как-то понять где начало и конец текста. в конечном итоге ты можешь скинуть сюда ссылку на репу со своей реализацией

а если я пошлю объект в 2 гига ?

очень просто: я закрываю соединение, если сообщение не укладывается в пакет :) на моих текущих сценариях проканывает (у меня веб сокеты в онлайн игре)

ты не понял примера?

я про то, что байты идут потоком и этот поток надо как-то делить

задержки в сети бывают самые разные, а это значит моя ситиуация, что я описал выше волне возможна

а специафикация тсп не гарантирует, где и как эти пакеты будут доставлены, это может быть как 100 байт за чтение, так и 8 кб

и сколько твоих пакетов ты считаешь за одинраз - не известно

Да нах два гига. MTU в районе 1500 байт у ethernet. А в зависимости от соединения и того меньше. Несколько килобайт и всё. сообщение уже приходит несколькими tcp пакетами. А с учётом задержек могу прийти два, отправленных в разное время.

Прикол с: буду слать и читать работает только на localhost

да боже... я примёл пример с 2мя гигамси

я понимаю что утрировано :)

ну а тогда в чём вопрос то? =)

в том что сообщнения надо делить)

и выше я предлагал пример, какой хеадер пакета-команды использую я

Помогите с оффтоп-вопросом, либо подскажите чат, где мне могут помочь. Есть программа Charles, которая ловит HTTP пакеты и позволяет заменять данные ответа сервера, но всё это делается вручную: 1. Поставил брейпоинт. 2. Дождался запроса. 3. Дождался ответа. 4. Изменит ответ. Вопрос вот в чём: как проводить все ти действия автоматически в Charles и, если никак, то какая программа сможет мне предложить такую функцию? P.S. Самому лень писать приложение прост :с

Ну смотрите, вот мой кусок кода, в котором я получаю текст: Socket ns = s.Accept(); byte[] buffer = new byte[1024]; int l; do { l = ns.Receive(buffer); Console.WriteLine(System.Text.Encoding.Unicode.GetString(buffer, 0, l)); } while (ns.Available > 0);Socket ns = s.Accept();

Ой, сейчас отформатирую.

попробуй пошли двумя командами: 1 команда (буква А) вторая команда (буква Б)

есть вероятность, больша, что ты считаешь АБ

Да я пробовал отправлять самые разные по длине сообщения, все приходили нормально...

А в чем вопрос-то тогда

на локал хосте?

)))

на локал хосте?

Нет, между компами в одной сети.

на самом деле, тебе советтуют как правильно) а ты делай как хзнаешь)

Да нет, я хочу сделать как правильно, конечно же. Просто хочу понять, что неправильного в моём коде. Вот отправлю я "А", сервер получит это, цикл отработает и завершится, а когда придет "Б" - это уже будет другой цикл же, как оно может смешаться...

оно может смешаться

это решаешь не ты =)

оно может смешаться

Если отправить сообщения в один момент?

Кто-нибудь пробовал райдер в связке с UWP/WPF? Как там с дебагом и скоростью? Шустрее VS?

один момент понятие растяжимое

сегоня есть задержки, завтра из нет

Кто-нибудь пробовал райдер в связке с UWP/WPF? Как там с дебагом и скоростью? Шустрее VS?

Что то мне подсказывает что там и поддержки их нет (он же крослпатформенный).

Ладно, буду читать еще... Всем спасибо за помощь!

Ладно, буду читать еще... Всем спасибо за помощь!

ты если хочешь, обращайся в личку, я уже достаточно давно работаю с сетью)

Что то мне подсказывает что там и поддержки их нет (он же крослпатформенный).

?

О, спасибо. Только сначала почитаю еще информацию по теме, а то туплю что-то).

сук

Еба

Вытираю это

Белова спам гроб-гроб кладбище #бан