1) в чём плохо если пользоваться этой конструкцией?

public static void AcceptCallback(IAsyncResult ar)
{
                listener = (Socket)ar.AsyncState;
                handler_worker = listener.EndAccept(ar);
        //обработка

                Instance.listener.BeginAccept(AcceptCallback, listener);
}

интересует именно почему в примерах не вызывают BeginAccept в собственном Callback (тоесть в собственном потоке) а используют отдельный поток и событие

2) если я сделаю так

    public void SendCurentWithoutTry(String cmd)
        {
            Encoding cp1251 = Encoding.GetEncoding(1251);
            byte[] для_отправки=cp1251.GetBytes(cmd);
            handle.BeginSend(cp1251.GetBytes(cmd), 0, для_отправки.Length, 0, new AsyncCallback(MySendCallback), handle);

        }
        private static void MySendCallback(IAsyncResult asyncResult)
        {
            try
            {
                Socket socket = (Socket)asyncResult.AsyncState;
                int размер=socket.EndSend(asyncResult);
            }
            catch (Exception ex)
            {

            }
        }

то при отправке длинных строк они не поделятся на фрагменты и не перемешаются? (то-есть отправится последовательно, непараллельно)
Заранее спасибо!!!

Здравствуйте, VVVa, Вы писали:

VVV>1) в чём плохо если пользоваться этой конструкцией?

Плохо тем, что APM лет 10 как legacy, и мало кто вспомнит, как оно работает.

Здравствуйте, VVVa, Вы писали:

VVV>интересует именно почему в примерах не вызывают BeginAccept в собственном Callback (тоесть в собственном потоке) а используют отдельный поток и событие

Почитай про IAsyncResult.CompletedSynchronously.

Здравствуйте, amironov79, Вы писали:

A>Здравствуйте, VVVa, Вы писали:

VVV>>интересует именно почему в примерах не вызывают BeginAccept в собственном Callback (тоесть в собственном потоке) а используют отдельный поток и событие

A>Почитай про IAsyncResult.CompletedSynchronously.

ну дак и что??? только этот параметр изменится и работать всё равно будет?

Здравствуйте, VVVa, Вы писали:
посмотрев документацию ужаснулся:
https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.beginsend?view=net-5.0

All I/O initiated by a given thread is canceled when that thread exits. A pending asynchronous operation can fail if the thread exits before the operation completes.

... значит если поток инициализировавший завершится до срабатывания — то будет ошибка
а можно ли его вызывать из ReadCallback который передаётся в BeginReceive? (или только если его остановишь до выполнения?) ведь просто send использовать нельзя?

Здравствуйте, VVVa, Вы писали:

A>>Почитай про IAsyncResult.CompletedSynchronously.

VVV>ну дак и что??? только этот параметр изменится и работать всё равно будет?

Что скрывается под "//обработка"? Если там есть синхронные вызовы, то программа может встать колом. Или вопрос про место вызова BeginAccept? Тогда минус твоей схемы в том, что для следующего accept надо ждать пока произведется "//обработка" нового соединения.

Здравствуйте, amironov79, Вы писали:

A>Что скрывается под "//обработка"? Если там есть синхронные вызовы, то программа может встать колом. Или вопрос про место вызова BeginAccept? Тогда минус твоей схемы в том, что для следующего accept надо ждать пока произведется "//обработка" нового соединения.

ОГО!!! неожиданно !!!
тоесть если в подпрограмме которую я передал в BeginAccept или BeginReceive будет вызов Send то может повиснуть? где про это написано???

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

как я понял если сокет присоединился асинхронно то синхронные методы для него применять нельзя? (опять про это в документации не написано)

Здравствуйте, VVVa, Вы писали:

VVV>ОГО!!! неожиданно !!!
VVV>тоесть если в подпрограмме которую я передал в BeginAccept или BeginReceive будет вызов Send то может повиснуть? где про это написано???

Если асинхронные вызовы будут выполняться синхронно (это не оксюморон) и Send заблокирует поток, то новые соединения некому будет обрабатывать.
Где написано? Уже не помню, было давно и неправда. Ключевые слова для поиска "CompletedSynchronously ThreadPool QueueUserWorkItem", но тема не популярная.


В воздухе висит вопрос: почему не async/await?

Здравствуйте, VVVa, Вы писали:

А всё таки расскажите чем не устроил TcpListener.AcceptSocketAsync / TcpListener.AcceptTcpClientAsync ?

Здравствуйте, VVVa, Вы писали:

Не всякий случай оставлю ссылку на сурцы выдранного сокет сервера из Kestrel. С меньшими усилиями, он вытягивается из Orleans.
https://github.com/dotnet/orleans/tree/master/src/Orleans.Core/Networking/Shared