[VB6]Winsock en hoeveelheid data

[pkouwer]

Ik sta op het punt een nieuwe toepassing te ontwikkelen, een client/server toepassing mbv Winsock. Ideen zijn e genoeg en geeft mij de gelegenheid om vertrouwd te raken me Winsock-programmering. Ik loop misschien wat op de zaken vooruit, maar ik vraag me het volgende af:


De serverapp. is de enige die verbinding heeft met een database. De client-apps roepen de data dus via de server op. Wat gebeurd er als ik redelijk kort achter elkaar twee oproepen doe en de eerste duurt langer dan de tweede. Hoe kan ik dan het beste in de client afvangen dat de gearriveerde data daadwerkelijk bij de tweede aanroep hoort ? Is die iets wat Winsock zelf regelt of moet ik hier een constructie voor bedenken ? Wat zijn jullie ervaringen ?

[Brahiewahiewa]

Dat moet je helemaal niet via winSock willen doen, maar via ODBC

[lier]

Je kan kiezen voor asynchroon programmeren. Vast ook wel een hoop over te vinden
Waarom VB6 ?

Dat moet je helemaal niet via winSock willen doen, maar via ODBC

Ehm...en waarom ? Gaat hier om de client - server communicatie.

[urk_forever]

Als je nu nog moet beginnen zou ik zeker niet meer met VB6 aan de slag gaan. Maar meer richting VB.Net ofzo gaan. Dan heb je volgens mij veel meer mogelijkheden mbt sockets, maar ook wbt threads ed.

[TeeDee]

Ben het met lier eens: waarom VB6? .Net geeft je hierin veel meer en mooiere mogelijkheden.

[pkouwer]

ik ben het wel eens dat .Net meer mogelijkheden heeft, maar op dit moment ontbreekt mij de kennis om dit in .Net te doen en ook de tijd om het te leren. De reden dat ik het met Winsocks wil doen is dat als er een record is toegevoegd, er direct (remote) actie ondernomen moet worden. Ik wil voorkomen dat ik continue databaseaanroepen moet doen.

[TeeDee]

VB6, Asynchronous en Socket programming zijn helaas keywords die de laatste tijd weinig tot geen resultaten op leveren.

In het verleden had ik altijd goede ervaring met SocketWrench. Deze hebben afaik nog steeds een Legacy build die je prima in je project kan gebruiken.

[? ?]

In VB6 is dat geen goed idee, ik meen zelfs dat de winsock ocx geheugen lekken heeft.
IN VB6 kun je dat wel asynchroon en meerdere sockets tegelijk:
gewoon de index van je winsock op 0 zetten, en dan heb je 32K sockets tot je beschikking in je winsock(0) luister je en geef je nieuwe aanvragen door naar een nieuwe winsock(index). Je moet dan wel een lijst bijhouden van welke indexen er in gebruik zijn enz.

Een webservice lijkt me toch eenvoudiger? En dan kun je ook vanalles doen na de request van de client.

[TeeDee]

En? Weet je al hoe je het e.e.a. in elkaar gaat zetten?

[pkouwer]

ik denk dat, gezien mijn kennis van VB.Net, hetgewoon VB6 met Winsocks wordt. Ik zal een routine moeten maken die mijn genoemde probleem ondervangt.

Kom ik bij een volgende vraag: wat is de beste manier (of gezien jullie ervaringen) om een recordset terug tegeven van de server naar de client ? Per record een send-command te sturen en als laatste een <EOD> end of data, te sturen, of alle records in een loop verzamelen en dit versturen ?

[pkouwer]

niemand een idee ?

[? ?]

noem eens één goeie reden waarom zo'n opstelling wil ?
En als je het dan toch wil doen, ga dan vooral niet je eigen tcp/ip server gaan schrijven, gebruik er een zoals bv IIS (asp.net) met een webservice als je per se "client" <-netwerk-> "server" wil

[ Voor 28% gewijzigd door ? ? op 19-03-2008 09:13 ]

[farlane]

era.zer schreef op dinsdag 18 maart 2008 @ 23:00:
noem eens één goeie reden waarom zo'n opstelling wil ?
En als je het dan toch wil doen, ga dan vooral niet je eigen tcp/ip server gaan schrijven, gebruik er een zoals bv IIS (asp.net)

IIS is een webserver, waarom haal je die erbij? Er kunnen verschillende redenen zijn om geen webserver te willen gebruiken.

[pkouwer]

pkouwer schreef op vrijdag 14 maart 2008 @ 10:09:
ik ben het wel eens dat .Net meer mogelijkheden heeft, maar op dit moment ontbreekt mij de kennis om dit in .Net te doen en ook de tijd om het te leren. De reden dat ik het met Winsocks wil doen is dat als er een record is toegevoegd, er direct (remote) actie ondernomen moet worden. Ik wil voorkomen dat ik continue databaseaanroepen moet doen.

volgens mij zijn dit redenen genoeg. Niet iedereen hier is fulltime programmeur, maar komt wel met ontwikkeling in aanraking. Dan moet je wel eens roeien met de riemen die je hebt.

[? ?]

Dus waarom zou je zoiets moeilijks gaan willen verzorgen als een netwerk verbinding tussen je client en je server? gebruik iets dat al bestaat. Roep een webservice aan op je client (dan heb je scheiding tussen client en database) en kun je vanalles doen voordat je de output terugverstuurt naar de client en hoef je je geen zorgen te maken over de tcp/ip verbinding. Zoiets is niet echt makkelijk als je 't voor 't eerst doet en weinig ervaring hebt en waarschijnlijk ook niet weet wat je aan't doen bent...
De beste manier? met zo weinig mogelijk overhead, dus query sturen, records krijgen. Hoe je die records gaat weergeven, fields delimiten enz is natuurlijk je eigen zaak, dat is nu net de bedoeling als je zelf met sockets wil werken

[ Voor 43% gewijzigd door ? ? op 19-03-2008 09:28 ]

[farlane]

era.zer schreef op woensdag 19 maart 2008 @ 09:18:
...De beste manier? met zo weinig mogelijk overhead

En een post daarvoor raad je nog een webservice aan. Over overhead gesproken.

[? ?]

Geeuw jezus
De "beste" manier is om zoveel mogelijk data in een keer te versturen zodat je connecties tot een minimum kunt houden, vooral in VB6
IIS regelt die webservice prima af en daar ga je ook een connectie maken en x aantal records teruggeven bijvoorbeeld. En de socketafhandeling van IIS is iets geavanceerder dan wat de TS gaat doen...

Maar doe vooral je eigen zin, kom binnen een maand eens terug en vertel eens hoever je staat en hoe stabiel alles is..

[farlane]

"Zelfs" in VB6 is het mogelijk om een applicatie te maken die stabiel draait inclusief TCP communicatie, de problemen die je daarbij tegenkomt zijn dezelfde als de problemen die je tegenkomt als je het met .NET zou doen. Die zijn niet specifiek voor een taal, maar inherent aan TCP communicatie in het algemeen.

Het pushen van events naar de clients vanuit een webserver is ook niet echt lekker, en het pollen van een webservice ... tja.

NB De memory leak waar jij het over hebt treedt alleen op als je het Winsock component gaat unloaden, wat sowieso niet nodig is.

[? ?]

't is lang geleden dat ik nog in VB6 geprogrammeerd heb, maar met één socket kun je één connectie aanvaarden? Je moet dus on the fly winsock objecten loaden (en unloaden als je ze niet meer gebruikt) voor elke connectie die je aanmaakt, terwijl er één vaste socket altijd luistert en het loaden en binden aan de andere beheert.

[ Voor 11% gewijzigd door ? ? op 19-03-2008 15:24 ]

[farlane]

era.zer schreef op woensdag 19 maart 2008 @ 15:19:
't is lang geleden dat ik nog in VB6 geprogrammeerd heb, maar met één socket kun je één connectie aanvaarden? Je moet dus on the fly winsock objecten loaden (en unloaden als je ze niet meer gebruikt) voor elke connectie die je aanmaakt, terwijl er één vaste socket altijd luistert en het loaden en binden aan de andere beheert.

Je moet ze loaden ja, maar als je dat hebt gedaan hoef je ze niet te unloaden, alleen een close en markeren als available voor een volgende accept is voldoende.

Overigens ga je niet in op het punt van pushen van events naar de clients vanuit jouw webserver, als ik dit lees:

De reden dat ik het met Winsocks wil doen is dat als er een record is toegevoegd, er direct (remote) actie ondernomen moet worden. Ik wil voorkomen dat ik continue databaseaanroepen moet doen.

is dat nl iets wat de TS wel wil.

[? ?]

Ik begreep dat als:
Nadat ik iets toevoeg wil ik remote (dus op de server) actie ondernemen, zoals een paar extra records hier of daar of weet ik veel.

En al zou het op de client moeten gebeuren: als er een actie is (insert) maakt client connectie met server, server insert en zendt berichtje naar client die z'n ding doet.

Je sockets niet unloaden? Dan blijf je er mee zitten, fun is dat, als er eens een piekje is, ga je zolang je de applicatie niet afsluit met 500 (of meer als het een grote piek is) geladen sockets blijven zitten; klinkt een beetje als windows 95 of erger, zeer professioneel.

[ Voor 69% gewijzigd door ? ? op 19-03-2008 20:17 ]

[pkouwer]

los van de gehele discussie sockets, IIS, loaden/unloaden of webservice, blijft mijn vraag hoe jullie ervaringen zijn als je op deze wijze te werk gaat. Ik heb nu een soort van header gevolgd door de records welke gescheiden zijn door bv <REC>. Middels een zooi split() commando's haal ik de gewenste informatie eruit en doe mijn ding.

graag reactie

[farlane]

pkouwer schreef op woensdag 19 maart 2008 @ 21:24:
los van de gehele discussie sockets, IIS, loaden/unloaden of webservice, blijft mijn vraag hoe jullie ervaringen zijn als je op deze wijze te werk gaat. Ik heb nu een soort van header gevolgd door de records welke gescheiden zijn door bv <REC>. Middels een zooi split() commando's haal ik de gewenste informatie eruit en doe mijn ding.

graag reactie

Grote nadeel daarvan is dat je eisen stelt aan de gegevens die in je record staan.

[pkouwer]

deze eisen zijn volgens mij vastgelegd in het database-model: ik weet wat er moet gaan komen on arrival

[? ?]

pkouwer schreef op woensdag 19 maart 2008 @ 21:24:
welke gescheiden zijn door bv <REC>.

En wat als er in je record de tekst "<REC>" voorkomt?
Je kan escapen, of data als base64 doorsturen, of gewoon...

[ Voor 44% gewijzigd door ? ? op 20-03-2008 15:20 ]

[pkouwer]

gelukkig heb ik dergelijke zaken in eigen hand;

gewoon wat ??

[ Voor 16% gewijzigd door pkouwer op 20-03-2008 16:57 ]

[farlane]

pkouwer schreef op donderdag 20 maart 2008 @ 14:16:
deze eisen zijn volgens mij vastgelegd in het database-model: ik weet wat er moet gaan komen on arrival

Hoe ga je in je databasemodel vastleggen dat er geen <REC> in je data mag staan dan?

[pkouwer]

Bij het invoeren van de data in de database, zal ik een aantal keywords moeten bepalen die niet ingevoerd mogen worden. Als iemand z'n NAW-gegevens moet ingeven, kan ik me trouwens niet voorstellen dat er netjes <REC> ingevoerd wordt. Zo ja, dan zal ik hier melding van moeten maken.

@Farlane: heb je andere tips dan ?

[alt-92]

pkouwer schreef op donderdag 20 maart 2008 @ 19:18:
Bij het invoeren van de data in de database, zal ik een aantal keywords moeten bepalen die niet ingevoerd mogen worden.

Kun je niet beter bepalen wat er wél ingevoerd mag worden?

[pkouwer]

ik zal de toepassing waarvoor ik het nodig denkt te hebben, wat toelichten:

het systeem is bedoelt om personen (lees: bezoekers) in te schrijven, althans dat gaan ze zelf doen middels een soort kiosk. Na het invoeren krijgen zij een nod ongeldige bezoekerspas. Bij de operator (is een gewoon werkstation elders op het terrein)komt er in het scherm een pop-up met de mededeling dat en nieuwe aanmeldingen zijn. De operator geeft zijn akkoord en de betreffende bezoekerspas wordt geauthoriseerd voor de entree.

Beide applicaties wil ik dus client maken, terwijl er een server tussen hangt voor al het verkeer. Zo heb ik minimale db-aanroepen. Anders moet de operator-applicatie, continue de DB afzoeken naar nieuwe aanmeldingen.

schept dit wat duidelijkheid of een ander beeld ?

[? ?]

[verhaal]
Ik heb een registratie applicatie gemaakt die bezoekers van een middelgroot bedrijf afhandelt. De bezoekers moeten na het registreren een opleiding doen aan een kiosk (taal, naam, ... kiezen, veiligheidsvideo kijken en nadien 10 vragen multiple choice oplossen. geslaagd=toegang tot bedrijf, anders niet). De beheerders applicatie pollt de wachtrij/resultaten van die opleiding elke 30 seconden.
Alles draait MSSQL server, er zijn 40+ bezoekers per dag, 15.000 bezoekjes per jaar.
Werkt perfect met polling, ik zie niet echt het probleem tenzij je 100 database-aanvragen per second hebt...
[/verhaal]
Ik had ook eerst een push in gedachten, maar heb het uiteindelijk niet gedaan.
Wat ik ging doen kan jij ook doen en is véle malen beter en simpeler dan de dataoverdracht zelf te moeten gaan verzorgen:

De applicaties waar je een push naar wil sturen, daar open je een socket op, en start je die, je luistert op een poort. Vervolgens Stuur je vanaf de clients waar de database insert op gebeurt een seintje naar de andere computer via het netwerk dat er nieuwe data is.
Zo heb je push op het juiste moment, maar moet je je geen zorgen maken over het versturen van data. Simpel en even effectief!

[pkouwer]

zit inderdaad wat in, dit maakt mijn serverapplicatie een stuk eenvoudiger. Ik wil wel met een soort van centrale applicatie werken omdat als de operator de software afsluit of al naar huis is, er geen bezoekers meer geregistreerd kunnen worden;