nem zsiványság: raw socket, melyik interfész, broadcast

Először is mindenkinek köszönöm a hozzászólást!
Mivel órákig nem jött semmi (anno) feladtam, és a "broadcast" csomagok helyett sima UDP csomagokat küldözgettem, különféle "fake" forráscímmel ellátva - a teszthez ez elégséges volt. Úgyhogy megkerültem a problémát :)
Meglepő, hogy a raw socket és az egyéb, nem szigorúan felhasználói kommunikációval kapcsolatban (pl. ICMP) milyen kevés az információ/specifikáció. Ráadásul, mivel mind winben mind Linuxban programozgatok - tudathasadásom is van, mivel a két rwendszer számos ponton alapvető dolgokat másképp kezel. Továbbra sem tudom, hogy a RAW socket melyik ethernet kártyára kapcsolódik - úgy tűnik, hogy az IP címhez illeszt valahogy (lehet hogy a másik szegmensre definiált interfész is megkapja, csak kiszűri?)

Egébként, most épp a windows ping -et "kerülgettem", számos alig olvasható forráskódot átnéztem, mindegyik az icmp.dll API -ra támaszkodik amit az M$ eléggé elkenve dokumentált, azt is csak a CE verzióra (MSDN, SDK és egyéb WEB források). Néha azon csodálkozom, hogy tud ez az egész működni amikor ilyen barkács!?

* Én egy indián vagyok. Minden indián hazudik.

Még mindig ugyanaz a projekt, de most kicsit más a gond.
Van egy kis raw socket küldözgető progim - kopasz C, az egész alig több 10 KB forrásnál. x.x.0.0 -tól x.x.3.254 -ig szór álvéletlen címekkel csomagokat. A program "magját" a csomag összeállítás képezi, teljesen szinkronban nyomja a csomagokat ahogy bírja. "Normál" (én annal tekintem állapotában ck. 2700 csomagot dob másodpercenként, a megadott cím és socket irányába. A túloldalon van a fejlesztés alatt álló program, ami veszi ezeket a csomagokat, és lerakja érkezési sorrendben egy fájlba, és ez windows -on zajlik. Azt kellet észrevennem, hogy időnként - teljesen változóan, akár 10 millió csomag után - egyszer csak kimerevedik, a log -ban azt látni, hogy az alsó réteg, eldobálja a csomagokat és a log FIFO teljesen betelik. Órákon át próbáltam mgérteni miért. össze-vissza trancsíroztam a kódot, míg rájöttem, hogy a primitív Linux oldali teszt programom időnként megvadul!? A szokásos 2.700 csomag helyett több mint 10.000 csomagot kezd küldeni! A Linux oldalt nem igen piszkálom, semmire sem használom, mitől tud ez így megtáltosodni? Hogy tudnám, valami egyszerű de biztonságos módon megfogni a sebességet?
(Kicsit lepusztult az agyam a sok órányi fölösleges debuggolástól)

* Én egy indián vagyok. Minden indián hazudik.

Mi lehet a hiba?

struture timespec upto, remain;
int i_lim, i_count;
...
i_count = atoi(argv[1]);
time(&upto.tv_sec);
upto.tv_sec++;
upto.tv_nsec = 0;
i_lim = 0;
do
{
//fill next packet
//send next packet
i_count--;
i_lim++;
if ( time(NULL) >= upto.tv_sec )
{
time(&upto.tv_sec);
upto.tv_sec++;
upto.tv_nsec = 0;
i_lim = 0;
}
if ( i_lim > 3000 )
{
nanosleep(&upto,&remain);
time(&upto.tv_sec);
upto.tv_sec++;
upto.tv_nsec = 0;
i_lim = 0;
}
} while ( i_count > 0 );


Időnként, beáll és vár!?

UI: miért nem tartja a formátumot a code elem sem?

* Én egy indián vagyok. Minden indián hazudik.

Valami már alakul, de nem az igazi :(
(Bocs de még mindig nem tudom hogy kell megadni az hogy ne törölje a sor eleji space -ket :()

struct timespec wait,remaind;
long long int elapsed, tick_start;
...
i_lim = 0;
start_tick = tick_nsec();
do
{
if ( ++ i_lim > 300 )
{
elapsed = tick_nsec() - tick_start;
if ( elapsed < 100000000L && elapsed > 1000000L )
{
wait.tv_sec = 0;
wait.tv_nsec = 100000000L - elapsed;
nanosleep(&wait,&remain);
}
start_tick = tick_nsec();
i_lim = 0;
}
// itt összeállítom és elküldöm a csomagot
} while ...


long long int tick_nsec()
{
struct timespec tspec;
clock_gettime(CLOCK_REALTIME,&tspec);
return ( (long long int)(tspec.tv_sec * 1000000000L + tspec.tv_nsec) )
}

Sajnos ez sem tökéletes, a windows oldal 100 ms -ként nézi meg a puffert, és általában kb. 300 csomagot kezel le, de van hogy több mint 600 -at, és a következő ciklusban nem jön semmi!?

* Én egy indián vagyok. Minden indián hazudik.