[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2021-01-05 Thread Malversán
Malversán added the comment: That means the core code also works for SOCK_RAW sockets. It's only limited by explicit socket type checks at a higher level. As a curious note (not related to the issue), I'm also using the SOCK_SEQPACKET connection created with BaseEventLoop to access a custom

[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2019-11-05 Thread Malversán
Malversán added the comment: I agree. Your question about potential message size overflow should be tested (either for recv() and recvmsg()). Could you please link the resource where you found the recommendation of using recvmsg() over recv() for SOCK_SEQ_PACKET

[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2019-11-04 Thread Malversán
Malversán added the comment: In my scenario that buffer overrun never happens, maybe because I use messages that are not big enough to overflow the default recv() buffer size. But I think I can confirm that multiple messages are never received in an atomic read, even if they are being issued

[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2019-11-04 Thread Malversán
Malversán added the comment: I do not have the answer about getting message boundaries at lower levels, but from a high-level point of view SOCK_SEQ_PACKET gives atomic reads, with no need to check for message boundaries yourself. Every time you read from a SOCK_SEQ_PACKET socket you get

[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2019-11-04 Thread Malversán
Malversán added the comment: It has a certain logic to recommend recvmsg() in place of recv(), as SOCK_SEQ_PACKET is characterized by transmitting entire messages only. But it has to be noted that my current hack (described above) is working for SOCK_SEQ_PACKET sockets with no modification

[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2019-09-26 Thread Malversán
Malversán added the comment: I'm sorry to read that. I thought the report could be enough to reach whoever put that SOCK_STREAM-only checks and ask him why, when the library actually works well also with other socket types. If I ever find enough time to dive into the CPython repository I

[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2019-09-26 Thread Malversán
Malversán added the comment: In the past it took me two days to analyze asyncio code, to think up and integrate the hack I´m using for this. But I´m not kidding when I tell you that it took me two years to find a while to come here and properly report it. I'm sorry, but I never have time

[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2019-09-26 Thread Malversán
Malversán added the comment: Certainly I have only tested it with SOCK_SEQPACKET, but apparently no one has ever tested this before with a socket type other than SOCK_STREAM. It may be worth to consider the possibility that the current asyncio implementation may also support some other

[issue38285] Asyncio BaseEventLoop can support socket types other than SOCK_STREAM

2019-09-26 Thread Malversán
New submission from Malversán : Currently the BaseEventLoop class in asyncio has explicit checks to raise ValueError when creating a connection if the socket argument has a type other than SOCK_STREAM: .create_connection() .create_server() This is also applicable for class