[C(++)/VxWorks] Efficiente manier 60 sockets te observeren

[Verwijderd]

Hallo iedereen,

Ik heb het volgende:
30 sockets voor realtime data (RTP) die per socket om de 15-35 ms data kunnen ontvangen EN
30 sockets voor signalling waarvan je gemiddeld om de 4 sec per socket iets kunt verwachten.

Mijn vraag is:
Hoe ga ik zo efficient mogelijk met de select()-call om icm met socket-data uitlezen. Het is de bedoeling om dit in 1 thread te stoppen, maar ik zou eventueel ook een thread per soort data kunenn doen (dus 1 voor RTP en 1 voor signalling).

Reden voor deze vraag is dat ik me afvraag of een FD_SET-van-alle-60-sockets en dan een single select() misschien niet echt handig is.

Ben benieuwd naar de antwoorden,

edit:
Zie ook een 5-tal berichten lager. Hier heb ik iets meer info gezet

EiSl

[ Voor 6% gewijzigd door Verwijderd op 05-09-2003 15:00 . Reden: Extra info ]

[curry684]

Reden voor deze vraag is dat ik me afvraag of een FD_SET-van-alle-60-sockets en dan een single select() misschien niet echt handig is.

Daar is het hele mechanisme juist voor bedoeld, dussuh: ja dat is handig

Verder zou het bijvoorbeeld handig zijn als je even je OS/platform zou vermelden (bij voorkeur in de topictitel zoals hier policy is).

[kasper_vk]

Uhm, over welke taal praten we hier?

[Verwijderd]

Ehh...
Kan topic niet wijzigen (of ik zie iets over het hoofd)
Maar het gaat om C/C++ mix voor embedded software (VxWorks), welke je heb beste met Unix/Linux omgeving kunt vergelijken.

[OkkE]

Alleen (lite-)modjes en admins kunnen topics wijzigen.

[curry684]

Binnen embedded is select helemaal ruim de beste oplossing.

[Verwijderd]

Misschien moet ik iets vollediger zijn (simplische code):

Optie 1: Alles in 1 taak:

code:

for (;;)
  FD_SET (voor alle 60 sockets)
  result = select( FD_SET.... )
  
  if ( result > 0 )   {
     for (elke socket) {
        if ( FD_ISSET( socket ) )
           Read_and_Process_Data(socket)
     }
  }

Optie 2: Opgesplitst:

code:

RTP_Thread::
for (;;)
  FD_SET (voor alle 30 RTP sockets)
  result = select( FD_SET.... )
  
  if ( result > 0 )   {
     for (elke socket) {
        if ( FD_ISSET( socket ) )
           Read_and_Process_Data(socket)
     }
  }

SignallingThread::
for (;;)
  FD_SET (voor alle 30 signalling sockets)
  result = select( FD_SET.... )
  
  if ( result > 0 )   {
     for (elke socket) {
        if ( FD_ISSET( socket ) )
           Read_and_Process_Data(socket)
     }
  }

Misschien maakt het ook uit in welke volgorde je de sockets in een FD_SET zet. Wellicht is het beter eerst de high-performance sockets erin te zetten en als laatste de langzamere signalling sockets...

edit:
Toegevoegd

Nu vroeg ik me net meteen het volgende af: is het noodzakelijk dat je voor elke keer dat je de select()-call induikt weer FD_ZER)/SET uitvoerd:

code:

    for (;;) {
      // Prepare file descriptor set for select-call
      FD_ZERO(&lv_ReadFds);
      FD_SET(lv_DataSocket, &lv_ReadFds); 
      // en bovenstaande SET 60x
      if ( select(....) ) { 
           Read_And_Process( ...  );
      }
  }

Als dit niet nodig is, dan hoef ik de ZERO/SET maar 1x uit te voeren.

You name it.. I build it

[ Voor 20% gewijzigd door Verwijderd op 05-09-2003 15:14 ]

[curry684]

Daar je embedded zit heb je naar ik mag aannemen alle CPU-tijd van het systeem tot je beschikking. Multithreading is in dat geval verspilling wegens scheduling, en een select(...) doet op kernelniveau waits plaatsen op alle opgegeven filedescriptors. Er is dus noch sprake van prioritizing binnen de lijst, noch van een voordeel bij multithreading. Mocht er veel processing voor een socket nodig zijn kun je beter met de gelezen data een worker thread afsplitsen.

[Verwijderd]

Daar je embedded zit heb je naar ik mag aannemen alle CPU-tijd van het systeem tot je beschikking. Multithreading is in dat geval verspilling wegens scheduling, en een select(...) doet op kernelniveau waits plaatsen op alle opgegeven filedescriptors. Er is dus noch sprake van prioritizing binnen de lijst, noch van een voordeel bij multithreading. Mocht er veel processing voor een socket nodig zijn kun je beter met de gelezen data een worker thread afsplitsen.

Nee mag/kan niet 100% CPU gebruiken
Gewuste systeem is onderdeel van een PABX-systeem met >1.000.000 regels code die dus wel heel wat meer doet dan wat ik er nu aan wil toevoegen. Niet alles is/kan interrupt driven, dus we gebruiken dus multithreading.

Maar bedankt voor je opmerking!
Het is me nu wel duidelijk wat te doen.