Цитата:
Сообщение от Konctantin
в итоге, они все равно складываются и записываются как один пакет, этот флаг ставится в самом процессе пакета, что знать что с ним делать дальше.
|
ну т.е. это чисто ваш какой то промежуточный флаг, связанный с вашей реализацией обработки данных? результирующий то хидер чанка в файле без флага?
Цитата:
Сообщение от Konctantin
|
всё, понял.
у меня сейчас тоже так же, свои экземпляры. но мне кажется это удобнее, чем в один файл писать.
на самом деле один файл со всеми сессиями нужно записать только один раз, что бы понять в какой последовательности слать пакеты, что бы реализовать эту фичу у себя на сервере.
но задайте честно себе вопрос. а вы правда будете использовать эту фичу у себя на сервере?
лично мне и из разных файлов понятно стало, что когда слать и что когда ожидать. ну это в общем личное.
Цитата:
Сообщение от LordJZ
У нас так получилось (и, я считаю, правильно), что переводом tcp траффика в классы типа Packet занимается один модуль, а собственно складыванием пакетов в файл — другой модуль, не имеющий самих данных из tcp пакета — т.е. только полезные данные. А размер там не нужен — есть byte[], у кого есть Length.
|
спору нет, я тоже считаю правильным, что каждый должен заниматься только своим делом. вот ваш byte[], у которого есть Length, собственно этот самый Length - кем, когда и из чего заполняется? наверняка так или иначе - из размера опкода
Цитата:
Сообщение от LordJZ
Дак зачем лишний раз обрабатывать исключение? Мы сделаем фиксированное количество байт в файле, и потом туда можно будет что-то приписать. Например, ту же подпись.
|
хмм... ну тут я опять в недоумении. это ж программа. всегда бывают исключения
смотрите:
- в вашем случае лишние данные, их подсчет, запись, потом их чтение. опять подсчет при чтении, сравнение. ну и что делать, если вдруг они не совпадут? реально (к примеру) один байт в конце потерялся, у последнего чанка. а снифф 50 мегов. все в помойку?
- в моем случае читаем до тех пор, пока не возникнет END_OF_FILE. всё