Ha _már_ meg vannak írva azok a programok, akkor már persze, hogy nincsen gond velük. Csakhát egy olyan alkalmazást ledebuggolni a fenének sincsen türelme. Nulláról újraírni pedig nem olyan egyszerű dolog.

Lehet majd kerítek valami tűzfalas szervert vhol, amin progikat futtathatok, és akkor ez a gondom megoldódik. Van itt esetleg egy rendszergazda, aki logint tud adni valami összeeszkábált koleszos gépre ? Bármilyen kicsike linux is remek lenne - persze kell rá gnu C fordító.

Addigis egy nagyon részletes tűzfal működési leírásra vadásznék továbbra is, ami informál róla, hogyan is használja a tűzfal a WAN felőli dinamikusan kiosztott portjait (tehát ami nincs pld virtuál servernek statikusan beállítva, hanem LAN felőli kommunikáció miatt aktuálisan osztotta ki).

őszintén szólva nem egészen értem a problémádat! Ugyanis tűzfal mögül is lehet broadcast adásokat hallgatni, vagy voice chatalni, ami udp.

Ki szeretném váltani a domain név / fix ip szolgáltatást egy automata "összesípolási" alkalmazással. Két állomás, mindkettő dinamikus IP-vel meg kellene találja egymást interneten. Amiket tudni lehet majd róluk:

-->egyszerűség kedvéért legyenek .ipA és .ipB állomások elnevezve
-->UDP protokollt kellene használni
-->.ipA tűzfal mögött lesz, de beállítva virtual serverrel, figyelni fog egy porton, ami fix, és ismerhető, legyen Aport (winsocketnél socket create, bind, receivefrom hívások)
-->.ipB szintén tűzfal mögött lesz, de virtual server nem lesz beállítva, a portját nem ismerjük, csak azt tudni róla, hogy lesz egy program indításkor meghatározott port nála is (Bport), ahol figyelni fog (amit a winsocket randomban dobott neki), alapjában ugyan az az eljárás (winsocket socket create, bind, receivefrom)
-->mindkét állomás C osztályú IP domainje ismert, de az utolsó digit nem, és az persze dinamikus, menet közben meg is "szakadhat", és olyankor lehet keresni újra.

Arra gondoltam, kezdeményezem a kommunikációt .ipB oldaláról, és elkezdek a domain alatt lévő összes IP címre üzenetet küldeni Aport-ra. Namost ha ezt pörgetem ciklusban, egyszercsak oda fog érkezni az üzenet, akárhányszor változik is .ipA, és akármekkora is a packet lost.

Amikor .ipA Aportja megkapta az üzenetet, látok ott egy küldő IP-t (.ipB), és egy küldő portot (Bport). Ugye az gyakorlatilag nem .ipB és Bport, hanem .ipB tűzfaljának dinamikus külső IP-je, és .ipB tűzfaljának egyik portja, amit ő kinyitott a csomag elküldésére.

A fő kérdés, hogy leszámítva a dinamikus ip várható megváltozását mennyire fogja akadályozni a kommunikációt .ipB tűzfalja ? TCP-nél tuti feljegyzi, hogy itt egy kiépített kapcsolat van, és neki kapcsolat bontásig azt a külső portot arra fent kell tartania, de UDP-nél nincsen kapcsolati alap (vagy valami mégiscsak van?).

Sajnos nem ismerem a mechanizmust, hogy UDP csomagküldéskor a tűzfal fent fog-e tartani ugyanúgy egy külső portot, amit kvázi átmeneti virtual serverként is használhatok, hogy oda választ küldjek .ipB-nek, vagy simán csak blokkot fog kapni minden válasz üzenetem. Perpill nem is tudok dupla tűzfalas hálózatot kiépíteni, hogy ezt saját kezűleg kikísérletezzem (pedig bizony megtenném). További problémám, hogy .ipA felől a válasz esetleg késni fog, és ha nyitva is fog tartani egy portot a tűzfal, mégis mennyi ideig teszi majd azt ? Meg lehet határozni valami minimum időt erre ? Pld hogy 5 percig még tuti nem zárja le ? Kezdetben azt feltételezem, hogy .ipB oldalán nem lesz gigászi adatforgalom, a tűzfal nyitva tudja majd tartani azt a portot, ha akarja. Más kérdés, hogy a szabványos protokolljai szerint mégis mit fog tenni ettől függetlenül.

A programírástól kezdve már elboldogulok a problémával, de az elméleti alapokból ezen a téren gyengusz vagyok.

------------------------------------------------------------------------
Összegezve:
Fentebbi kérdések megválaszolásához keresek doksit, avagy pár gyors felvilágosítás is elég lenne, hogyan is fog "gondolkodni" az a tűzfal ?