[i know its somewhat og topic ass it is not on language but
it is on programming in c so imo such things are on topic too]

i never got time/opportunity to learn networking (in last years
i almost no code, tryin to do something more on say 'literature'
with not much result)

hovver i recently decided to maybe understand sockets a bit,
so maybe someone will explain it a bit to me

im not sure but as i understend crucial is send and recv commends
and both are blocking (?)

working with such blocking comends is totally silly imo and it must
be mayeb soem artifact of old ages as its total nonsense (as it
blocks two machines)

as its nonesense the right way would be using non blocking send and recv
but it yeilds to
1) could someone write to me (may be in pseudocode) how to muke such
non blocking commands
2) it this worx nonblocking i quess that network devise or maybe
its driver must queue incomoing packets - so the send and recv
would not block but just put and get things in queue (and that is
right thing imo) - but the question is ..it there some knowledge
on how those queues are, lika capacity and legel assumptions to
get on them, etc?

i think if nonblocking send/recv are right way those queues importance
is crucial and i would like to understand it

tnx, fir (first tme on some newsreader)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Spiros Bousbouras wrote:

On Wed, 07 Feb 2024 23:49:14 +0100
fir <fir@grunge.pl> wrote:

[i know its somewhat og topic ass it is not on language but
it is on programming in c so imo such things are on topic too]

No they aren't. A huge variety of different stuff are programmed in C. If we tried to discuss all of them here , it would be chaotic.

it could be chaotic but it also be not chaotic so generally the answer
is nor no nor yes some like "yesno" and maybe it is better to be open on
yesno themes

as to this sockets i think that this 'queue' of packets must be a
crucial thing here

without it its probably not possible (or nearly) to do such network communication based on packets and if so the details of it would be
also very important i guess

What you're really asking in non blocking I/O. This is operating system specific. For Unix/Linux the right place is comp.unix.programmer .But I think you are on Windows. I don't know what is the Windows analog for comp.unix.programmer .Perhaps someone else does.

i never got time/opportunity to learn networking (in last years
i almost no code, tryin to do something more on say 'literature'
with not much result)

hovver i recently decided to maybe understand sockets a bit,
so maybe someone will explain it a bit to me

You can start with https://en.wikipedia.org/wiki/Network_socket .

im not sure but as i understend crucial is send and recv commends
and both are blocking (?)

working with such blocking comends is totally silly imo and it must
be mayeb soem artifact of old ages as its total nonsense (as it
blocks two machines)

as its nonesense the right way would be using non blocking send and recv
but it yeilds to
1) could someone write to me (may be in pseudocode) how to muke such
non blocking commands

If you want pseudocode (i.e. more abstract than operating system specific) then you want comp.programming .

2) it this worx nonblocking i quess that network devise or maybe
its driver must queue incomoing packets - so the send and recv
would not block but just put and get things in queue (and that is
right thing imo) - but the question is ..it there some knowledge
on how those queues are, lika capacity and legel assumptions to
get on them, etc?

i think if nonblocking send/recv are right way those queues importance
is crucial and i would like to understand it

tnx, fir (first tme on some newsreader)

Congratulations.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 07 Feb 2024 23:49:14 +0100, fir wrote:

im not sure but as i understend crucial is send and recv commends and
both are blocking (?)

Correct--by default, anyway. It is possible to set O_NONBLOCK on them <manpages.debian.org/7/socket.en.html>. But then you just get EAGAIN
errors when trying to read or write. Assuming you don’t want to sit in a CPU-bound polling loop, the easiest way to monitor multiple sources of
events concurrently is with a call like poll(2) <manpages.debian.org/2/poll.en.html>.

There is also the option of using multiple threads, each blocking on a
single socket, with some IPC scheme to coordinate between them. But that
gets complicated, and prone to heisenbugs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)