BlackGnomeГуест,
зависит все от требований заказчика.
Если он конкретно говорит о том, что сеть должна быть только такой, то это нужно учитывать. Если же не говорит, и предоставляет все определить исполнителю, ставя ограничения только по бюджету, то нечего думать о требовании к сети, не определившись с требованиями к приложению.
А тут все туманнее. Пользователь может затребовать функционал, который просто потребует реализации некоего сеансового общения, а не просто сообщений. Можно и асинхронно вызывать, можно синхронно. Вопрос - зачем?
Что требуется от того, кто посылает и от того, кто принимает?
Если требуется некая гарантийная доставка данных, то придется давать подтверждение получателем о получении данных. При этом, по сути неважно, сихронка или асинхронка, ибо даже программное корректное завершение синхронного вызова не гарантирует, что пользователь данные ОБРАБОТАЛ до конца. Хотя может он их и получил, то есть УВИДЕЛ.
Ну, скажем, накрылся у него бук, когда он их смотрел. Что дальше? Как восстановить то, что он потерял? То есть речь идет о возможности восстановления данных, а вот для этого и треба ввести подтверждение, а не просто синхронку.
Можно все запихнуть в синхронку, если она по окончанию гарантирует, что полученные данные больше не перезапросит (даже в случае падения бука, тогда она должна где-то на буке их сохранять)
Тут однако еще вопрос встает. А если сервер должен будет поддерживать несколько тысяч клиентов, то во что ему выльется синхронное удержание канала даже на 0.1 секунду? Это критично для тех, кто ждет освобождение канала, ил инет? Ибо 1000-я станция из этого канала получит новые данные только через 1.40 секунд.. А за это время они уже набуй ей не нужны, если, скажем, речь идет о каких-то котировках, То естm придется как-то рулить всем этим хозяйством..