Citat:
Da osiguram npr. da ce log fajl ofstreamovi biti ispraznjeni (flush)
Imao sam jednom slicnu dilemu i problem, barem mi se cini prema tvom opisu.
Razvijao sam sistem za obavestavanje (email, sms, posebne lan poruke) o alarmnim signalima rada termoblokova u realnom vremenu . E sad, 'glavni' program (i on je bio servis) je u realnom vremenu i u realnim situacijama proizvodio veliki broj 'informacija' koje je trebalo proslediti na sms, email i sl. Nekada stotine i hiljade na sat.
Taj program je sam po sebi bio osetljiv (jos je bio u razvoju) i nikako nisam smeo buffer NEOBRADJENIH (neposlatih) poruka funkcionalno u celosti prepustiti njemu samom. Upravo zbog potencijalnog pucanja, a naravno i zbog pametnijeg dizajna.
Na primer, pucanje i restart programa (u nekom RANDOM trenutku) se moglo manifestovati ponovnim slanjem vec poslatih SMS-ova ili jos gore ne-slanjem onoga sto je moralo biti poslato.
Citat:
Sta preporucujes za brzu komunikaciju izmedju procesa (nikakvo XML-oavnje i ni bajt preko diska)?
Onda sam prosto napravio tri zasebna servisa SMSServer, LANServer i EMAILServer kojima sam sto je pre bilo moguce prosledjivao sadrzaj onoga sto je bilo za slanje, a ti veliki bufferi su bili sada u njihovoj nadleznosti. Ti programi (servisi) su sami po sebi bili dosta jednostavni, a time i pouzdani.
Slanje sam realizovao 'obicnim' TCP/IP socket-ima, sto je ekstra brzo.
Mogu se za komunikaciju koristi jos brojne stvari tipa "Named pipes", i sl... mozda i Shared memory blokovi. Dakle, nema prethodnog upisa na disk.