i slightly thinked on how socket programing shpuld look
like in c (in pseudocode) maybe something like this
(a bit in pseudocode)




main() //client
{
int id = connect("adress", port);

for(int i=0; i<100; i++) // repeat 100x 10ms wait on connection done
{
if(connected(id)) goto connected:
sleep(10);
}

non_connected:

exit("non connected");

connected:

for(;;)
{
int n = received_packets(id)
for(int i=0; i<n;i++)
{
char* data = recv(id);
printf("%s", data);

}
sleep(10);

}


}
and encountered a case where you would like to get
else clausule after for in c (not first time)

it is becouse if you get something to appear in loop
if it appear you can break and continue but if it will not
you will ned to do something else

and without this else clause you must use gotos, which is not
a big problem but it overally shows that this for may need
an else

(not to say its good idea as for else yet with break dont look to much
optimal probably but its sorta interesting notice i think

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

Lawrence D'Oliveiro wrote:

On Thu, 08 Feb 2024 00:18:53 +0100, fir wrote:

sleep(10);

What if packets arrive faster than that?

you see i mentioned my reasoning that packed queue must be crucial
to such incoming packets communication methods so alongside the recv
command to get one packet you would preferably get more functions
for thsi queue at least one that informs you how manty pockets on
queue there is

see in that pseudocode

for(;;)
{
int n = received_packets(id) // <--- here
for(int i=0; i<n;i++)
{
char* data = recv(id);
printf("%s", data);

}
sleep(10);

}

i think depending on case you would have such situations when you
wuould probably prefer to store number of packets and only them
read many of them - i dont know maybe wideo sttreaming or something
would use that ? (i got no experience in any socked programming)

instead how they done it in wideo streaming they got a cpu-bound intense
loop when they copy heavy thousand of packets into some array? then take
a break and render id ? (if so when they render packets probably will
also queue in some network device queue, or they always have
rendering thread separatelly to packet receiving thread?
i guess the packets are received by network card whuch has its own
processor probably soit dont need a separate thread i guess only
a piece of ram for a packet queue

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

On Thu, 08 Feb 2024 00:18:53 +0100, fir wrote:

sleep(10);

What if packets arrive faster than that?

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

fir wrote:

Lawrence D'Oliveiro wrote:

On Thu, 08 Feb 2024 00:18:53 +0100, fir wrote:

sleep(10);

What if packets arrive faster than that?

you see i mentioned my reasoning that packed queue must be crucial
to such incoming packets communication methods so alongside the recv
command to get one packet you would preferably get more functions
for thsi queue at least one that informs you how manty pockets on
queue there is

see in that pseudocode

for(;;)
{
int n = received_packets(id) // <--- here
for(int i=0; i<n;i++)
{
char* data = recv(id);
printf("%s", data);

}
sleep(10);

}

i think depending on case you would have such situations when you
wuould probably prefer to store number of packets and only them
read many of them - i dont know maybe wideo sttreaming or something
would use that ? (i got no experience in any socked programming)

instead how they done it in wideo streaming they got a cpu-bound intense
loop when they copy heavy thousand of packets into some array? then take
a break and render id ? (if so when they render packets probably will
also queue in some network device queue, or they always have
rendering thread separatelly to packet receiving thread?
i guess the packets are received by network card whuch has its own
processor probably soit dont need a separate thread i guess only
a piece of ram for a packet queue

im not sure though how the server code would look like
(probably the server name here not quite fits as its rather
client who invites for connections, inviter/invitator maybe)


so if client connects() the invitator should invite()
and has a queue not only for packets but also for 'guests'






work_with_guest(int guest_id)
{
int tag = get_tag(guest_id); //tag firld in quests queue used to
note state of interaction

if(tag==0)
{
send(guest_id, "hello");
set_tag(guest_id,1);

}

//here also acces queue of guest incoming packets


}

main() //server
{
int id = invite( port);

for(;;)
{

int n=get_guest_queue_length(id)
for(int i=0; i<n;i++) //interract with all quests
{
work_with_guest(i);
}

sleep(5);
}


}


i would write it this way probably but the sockets that there are are
rather confusing and for now i dont know how to implement things like this

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

On 2024-02-07, fir <fir@grunge.pl> wrote:

i slightly thinked on how socket programing shpuld look
like in c (in pseudocode) maybe something like this
(a bit in pseudocode)

https://www.youtube.com/watch?v=hE-thwqI3P4&t=48s

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

Kaz Kylheku wrote:

On 2024-02-07, fir <fir@grunge.pl> wrote:

i slightly thinked on how socket programing shpuld look
like in c (in pseudocode) maybe something like this
(a bit in pseudocode)

https://www.youtube.com/watch?v=hE-thwqI3P4&t=48s

dat is how you singing? i got no time for that

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