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

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

> sleep(10);

What if packets arrive faster than that?

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

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

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

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