[partiallo off topic] on sockets - and how it should be done

[fir]

[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)

[Spiros Bousbouras]

On Wed, 07 Feb 2024 23:49:14 +0100
fir <f...@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.

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.

--
Caveat Emptor: The cost of software maintenance increases with the
square of the programmer's creativity.
First Law of Programmer Creativity, Robert D. Bliss, 1992

[fir]

Spiros Bousbouras wrote:
> On Wed, 07 Feb 2024 23:49:14 +0100
> fir <f...@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

[Lawrence D'Oliveiro]

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.

[Keith Thompson]

fir <f...@grunge.pl> writes:
> Spiros Bousbouras wrote:
>> On Wed, 07 Feb 2024 23:49:14 +0100
>> fir <f...@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

[...]

You're more likely to find people who can answer your questions in
comp.unix.programmer or (I think) comp.os.ms-windows.programmer.win32,
depending on your environment.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */