1. так как это р2р, то ноды должны асинхронно общаться друг с другом(инициатор может быть на любом конце)
но я не понял как это сделать с одним соединением, писать и читать там конечно можно в оба направления, но как достичь синхронизации не ясно и наврено нереально или я чего-то не знаю (чтобы один не начал писать свой запрос когда другой ждет от него ответ)
поэтому на любое входящее соединеие создаю ответное, это правильно?
2.
этот подход работает локально и по локальной сети, а по инету чето не работает, удаленный узел может подключиться к моей рабочей тачке, а мой к удаленному — не может — почему?
порты проброшены файрволы выключены
CORE 3.1
слушаю так:
Listener = new TcpListener(IPAddress.Any, Port);
Listener.Start();
подключаюсь так:
var client = new TcpClient(); // вопрос 2а: есть такой конструктор - new TcpClient(addr) - который выглядит бесполезным потому что никуда не конктится и вообще не соотв-ет документации - что это за хрень?
client.Connect(addr);
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Listener = new TcpListener(IPAddress.Any, Port);
B>Listener.Start();
B>
B>подключаюсь так:
B>
var client = new TcpClient(); // вопрос 2а: есть такой конструктор - new TcpClient(addr) - который выглядит бесполезным потому что никуда не конктится и вообще не соотв-ет документации - что это за хрень?
B>client.Connect(addr);
B>
Здравствуйте, Barbar1an, Вы писали:
B>1. так как это р2р, то ноды должны асинхронно общаться друг с другом(инициатор может быть на любом конце) B>но я не понял как это сделать с одним соединением, писать и читать там конечно можно в оба направления, но как достичь синхронизации не ясно и наврено нереально или я чего-то не знаю (чтобы один не начал писать свой запрос когда другой ждет от него ответ) B>поэтому на любое входящее соединеие создаю ответное, это правильно?
Я бы делал наоборот: ограничивался одним соединением и специально отсекал бы случаи, когда оба узла одновременно захотели друг друга, и в результате получилось два соединения.
B>этот подход работает локально и по локальной сети, а по инету чето не работает, удаленный узел может подключиться к моей рабочей тачке, а мой к удаленному — не может — почему? B>порты проброшены файрволы выключены
Да кто знает-то? Открой для себя Wireshark, и научись им пользоваться. Без этого умения серьезную сетевую программу не написать.
Здравствуйте, Pzz, Вы писали:
Pzz>Потому, что если твой p2p работает только при условии, что пользователь выключил NAT и firewall, то он никому не нужен.
нууууу вроде например торрнет и биткоин работают по tcp и ниче, не знаю как школота НАТы пробрасывает но както похоже пробрасывает, и не выключает, зачем выключать?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Pzz, Вы писали:
Pzz>Я бы делал наоборот: ограничивался одним соединением и специально отсекал бы случаи, когда оба узла одновременно захотели друг друга, и в результате получилось два соединения.
ну а как я с таким подходом сделаю обмен с инициаторами на обоих концах? даже в теории я не вижу такого механизма синхронизации, потому что в сети ничего атомарного не бывает
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>ну а как я с таким подходом сделаю обмен с инициаторами на обоих концах? даже в теории я не вижу такого механизма синхронизации, потому что в сети ничего атомарного не бывает
Значит, тебе придется изобрести алкогоритм, который в конечном итоге будет приходить в это состояние.
P.S. Когда я занимался подобными вещами, у меня узлы на камень-ножницы решали, кто из них главный в этой паре, и побеждало соединение, инициированное главным узлом.
Здравствуйте, Barbar1an, Вы писали:
Pzz>>Потому, что если твой p2p работает только при условии, что пользователь выключил NAT и firewall, то он никому не нужен.
B>нууууу вроде например торрнет и биткоин работают по tcp и ниче, не знаю как школота НАТы пробрасывает но както похоже пробрасывает, и не выключает, зачем выключать?
Здравствуйте, Pzz, Вы писали:
Pzz>P.S. Когда я занимался подобными вещами, у меня узлы на камень-ножницы решали, кто из них главный в этой паре, и побеждало соединение, инициированное главным узлом.
опять не поняли
представьте что у вас на каждом конце и вебсервер и браузер, вот это и есть наш р2р
решить кто главный не проблема, проблема когда у вас на двух концах происходят непредсказуемые события и вам нада передавать их в режиме запрос-ответ, а каналов записи и чтения у вас по 1 шт
впрочем почесав аллопецию я понял что эта проблема имеет простое решение — обязательная очередность.
т.е. каждый узел может отправлять запрос только после того как обработает входящий, т.е. иницирируют короткие сессии они сторого по очереди,
1 пишет 2 отвечает
2 пишет 1 отвечает
1 пишет 2 отвечает
...
если узлу отправлять нечего то он отправляет пустой пакет
соотв-но если узлам вообще нечем обмениваться то они просто лениво спериодом типа 10 сек перекидыются пустыми пакетами
вот и всё,
а вы тут развели, читай книжки, наты, только удп только хардкор и прочее, хотя все равно спасибо это уже не первый раз когда куча народу ничем толком мне не помогает но както всё равно наталкивает на нужные идеи
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>решить кто главный не проблема, проблема когда у вас на двух концах происходят непредсказуемые события и вам нада передавать их в режиме запрос-ответ, а каналов записи и чтения у вас по 1 шт
Ну и кто мешает поток независимых сообщений гнать в обе стороны по одному TCP-соединению?
B>вот и всё, B>а вы тут развели, читай книжки, наты, только удп только хардкор и прочее, хотя все равно спасибо это уже не первый раз когда куча народу ничем толком мне не помогает но както всё равно наталкивает на нужные идеи
Когда человек ничего незнает, ему нередко кажется, что вокруг одни идиоты. Потом это проходит. Но не у всех.
Pzz>Ну и кто мешает поток независимых сообщений гнать в обе стороны по одному TCP-соединению?
в режиме запрос-ответ
в режиме запрос-ответ
в режиме запрос-ответ
можно конечно там организовать очереди пакетов, всем запросам давать идентификаторы, блокировать потоки в ожидании прихода нужного ответа, но зачем тогда tcp? такое и на udp можно сделать
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
Pzz>>Ну и кто мешает поток независимых сообщений гнать в обе стороны по одному TCP-соединению?
B>в режиме запрос-ответ B>в режиме запрос-ответ B>в режиме запрос-ответ
Ну и сведи запросы с ответами, какая проблема?
B>можно конечно там организовать очереди пакетов, всем запросам давать идентификаторы, блокировать потоки в ожидании прихода нужного ответа, но зачем тогда tcp? такое и на udp можно сделать
Затем, что tcp еще делает flow control и retransmit. Это в разы сложнее того, что ты перечислил.
