TCP relay tooltje

[michaelbar]

Beste mede Tweakers,

Ik heb echt een stom probleem, stom omdat het vast super makkelijk is...

Daar ik echt niet kan pogrameren, maar echt wel veel snap van netwerken, weet ik dat dit een stomme vraag is, maar toch, ik moet het helaas vragen... want ik kom maar niet vooruit

Kan iemand mij wijzen op een simpele tool (GNU/freeware) om een 'data stream' die via TCP binnen komt te dupliceren?

Het volgende moet kunnen:

1. Setup (ik denk aan via een .ini of .xml)
2. Service installation
3. Source en destination sockets laten opzetten als zowel server als client connecties
4. Moet meerdere clients kunnen serven

Hoe dan ook moet de tool connecten aan een 'server' (op TCP niveau), daarna komt de data stream van de server naar de tool. De resulterende data flow moet dan door de 'simpele tool' beschikbaar worden (server) voor meerdere 'connecting clients' (clients) (oa. een putty sessie die de data logged). De tool moet meerdere connecties toe kunnen laten (van nog meer putty clients). Bandbreedte is niet belangrijk, de hoeveelheid data is klein.

Please help

[ Voor 22% gewijzigd door michaelbar op 21-02-2018 11:53 ]

[MAX3400]

Moet je dan niet gewoon eens zoeken naar promiscuous mode van je port?

No offense maar de vraag klinkt, afhankelijk aan welke kant van de source-IP je staat zowel "grijs gebied" alsmede "copyrighting" alsmede "afluistertechniekjes".

[ik222]

Misschien moet je even vermelden wat je functioneel wilt bereiken.

[CyBeR]

Wat wil je bereiken met dit idee?

[MerijnB]

Je hebt het over tcp, meerdere clients die verbinden en unicast.

Zover ik weet:
- unicast is niet data naar meerdere clients sturen, dat is multicast
- multicast is UDP geen tcp

Daarbij, wat verwacht je dat er moet gebeuren als zo'n client iets terugstuurt?

[Gomez12]

Ik zou je boeken over netwerken er nog maar eens goed bij gaan pakken.

Want dit is juist niet super makkelijk en de problematiek zit hem 99% in de netwerkkant.

Wat wel te doen is is een repeater opzetten die een tcp-pakketje opvangt en dit zelf opnieuw verstuurt naar 1 of meerdere clients, alleen dat vereist wel inhoudelijke kennis over het tcp-verkeer want je moet het pakketje opnieuw samenstellen.

Maar maak eens duidelijk wat de toepassing is, want ik vermoed dat de oplossing veel simpeler is als je niet naar netwerk-verkeer gaat kijken maar gewoon naar data-streams.

[twilightschild]

Collega van TS hier. De terminologie die gebruikt wordt klopt niet helemaal, dus misschien kan ik wat licht op de zaak schijnen:

Wat hij wil is een tooltje die verbindt aan een TCP server (extern) en alle data die van die verbinding afkomt doorstuurt naar TCP clients die aan de tool verbinden. Het gaat dus eigenlijk om een simpel forwarding tooltje. Er hoeft geen data van de clients naar de server toe.
Er is geen sprak van schimmige praktijken, de TCP feed wordt ter beschikking gesteld aan ons, maar kan om de 1 of andere reden maar 1 connectie aan. Ik geloof (maar weet niet zeker) dat TS de data wil loggen, maar nog steeds een mogelijkheid wil bieden voor collega's om te verbinden aan de stream.

TS is specifiek op zoek naar een bestaande tool die kan draaien als service om dit te doen. IP en poort van zowel externe server (waar de data vandaan komt) als de zelf gehoste server (waar interne clients op connecten) moeten configureerbaar zijn.

(We zijn op de hoogte dat dit met een paar regels python geregeld is, maar TS wil liever een tooltje)

Hoop dat het zo wat duidelijker is. Succes @michaelbar

[Garyu]

Zoiets? https://packetsender.com

Er wordt geen OS genoemd? Windows of Linux?

[michaelbar]

Garyu schreef op dinsdag 20 februari 2018 @ 17:36:
Zoiets? https://packetsender.com

Er wordt geen OS genoemd? Windows of Linux?

Hi allen,

Voor alle duidelijkheid betreft het een windows server

Alvorens dank.

[ Voor 52% gewijzigd door michaelbar op 20-02-2018 17:55 ]

[LoBbY_1]

Over netwerken gesproken - Je hebt ook simpele switches die poort duplicatie doen.

[Orion84]

Die TCP servers en clients in kwestie praten natuurlijk niet enkel maar TCP, die praten een bepaald applicatieprotocol. Je kan dus ook niet domweg op de netwerklaag dingen gaan dupliceren of relayen. Je zal op de 'proxy' eenmalig de verbinding met de server op moeten zetten en vervolgens een server moeten draaien waar de clients naar verbinden en die dan de data doorsturen die je van de originele server ontvangt.

Ik zie niet hoe je dit anders gaat oplossen dan met een tool die daadwerkelijk het betreffende applicatie protocol ondersteunt?

[twilightschild]

Orion84 schreef op dinsdag 20 februari 2018 @ 18:00:
Die TCP servers en clients in kwestie praten natuurlijk niet enkel maar TCP, die praten een bepaald applicatieprotocol. Je kan dus ook niet domweg op de netwerklaag dingen gaan dupliceren of relayen. Je zal op de 'proxy' eenmalig de verbinding met de server op moeten zetten en vervolgens een server moeten draaien waar de clients naar verbinden en die dan de data doorsturen die je van de originele server ontvangt.

Ik zie niet hoe je dit anders gaat oplossen dan met een tool die daadwerkelijk het betreffende applicatie protocol ondersteunt?

Er is geen applicatieprotocol. Het is een simpele unidirectionele datastroom. De applicatie hoeft dus niets anders te doen dat de ontvangen data door te sturen naar de clients.

[MAX3400]

Port mirroring dan maar? Of nog dommer; alle clients een static IP geven en op een hub hangen "want broadcast"...

[DiedX]

Haproxy?

[Gomez12]

twilightschild schreef op dinsdag 20 februari 2018 @ 18:32:
[...]
Er is geen applicatieprotocol. Het is een simpele unidirectionele datastroom. De applicatie hoeft dus niets anders te doen dat de ontvangen data door te sturen naar de clients.

TCP is by definition niet unidirectioneel maar bi-directioneel. Als wat jij en je collega beschrijven klopt dan zou je het hebben over UDP en niet TCP.

Ik zou zeggen kijk eens naar het verschil tussen UDP en TCP en je snapt waarom je een forwarder voor TCP niet maakt met een paar regels python, met een paar regels python maak je een applicatie protocol proxy.

Ik zou zeggen maak die paar regels python gewoon en gebruik dat, want nu zoek je op totaal verkeerde terminologie en naar totaal verkeerde dingen.
Voor wat jullie willen is er geen echte applicatie oplossing kant en klaar, omdat het totaal afhankelijk is van het applicatie protocol.

MAX3400 schreef op dinsdag 20 februari 2018 @ 18:35:
Port mirroring dan maar? Of nog dommer; alle clients een static IP geven en op een hub hangen "want broadcast"...

Port mirroring kan wel, maar hub lijkt me totaal niet handig, mag je alle conflicten die hieruit gaan voortkomen op client niveau gaan fixen.

DiedX schreef op dinsdag 20 februari 2018 @ 18:42:
Haproxy?

Dat hangt dus er net vanaf of die het applicatie protocol ondersteunt en verstaat.

Ikzelf zou het ook gewoon in een simpel homemade tooltje stouwen aangezien dat in een middag te maken is en je voor de rest alleen maar op giga-pakketten gaat uitkomen die moeilijker te configureren zijn dan het schrijven van het home-made tooltje.
Als er echt een bedrijfsbelang achter zit dan kan het een goede oplossing vereisen, maar TS die enkel een stroompje data wil ontvangen dat verdient niets meer dan een home-made tooltje.

[twilightschild]

Gomez12 schreef op dinsdag 20 februari 2018 @ 22:37:
[...]

TCP is by definition niet unidirectioneel maar bi-directioneel. Als wat jij en je collega beschrijven klopt dan zou je het hebben over UDP en niet TCP.

Dit is dan ook geen opmerking over TCP, maar over het 'applicatieprotocol'. Ik merk op dat er niet echt een applicatieprotocol is omdat (wederom op applicatieniveau) de communicatie uni-directioneel is. Nadat de verbinding tot stand is gebracht stuurt de server een continue stroom data naar de client. De client stuurt nooit data naar de server.

Gomez12 schreef op dinsdag 20 februari 2018 @ 22:37:
[...]
Ik zou zeggen kijk eens naar het verschil tussen UDP en TCP en je snapt waarom je een forwarder voor TCP niet maakt met een paar regels python, met een paar regels python maak je een applicatie protocol proxy.

Ik denk dat ik dat verschil vrij goed begrijp, maar wellicht ben ik er niet in geslaagd om goed duidelijk te maken wat TS echt wil. Lang verhaal kort: zo'n applicatieprotocolproxy is precies wat hij nodig heeft.

[Gomez12]

twilightschild schreef op dinsdag 20 februari 2018 @ 23:30:
[...]
Lang verhaal kort: zo'n applicatieprotocolproxy is precies wat hij nodig heeft.

Lang verhaal ook kort dan : Schrijf dat ding zelf. Of het moet gaan over een standaardprotocol, of je praat per definitie over een stuk maatwerk.

[base_]

port mirror + wireshark? Leer je meteen wat dat TCP nou precies inhoudt En waarom je dat verkeer niet zomaar kan dupliceren op hetzelfde netwerk (dat gaat de switch niet leuk vinden bijvoorbeeld, vandaar dat je een switch moet hebben die dit voor je doet...).

[Brahiewahiewa]

Jullie denken veeel te moeilijk. D'r is gewoon één source en meerdere clients en kennelijk kan die source niet met meerdere clients omgaan. Om dat succesvol te kunnen frauderen laat je die client slechts op één machine draaien draaien (de server) en z'n output uitspugen naar html. Alle andere clients connecten naar die html-stream

[MerijnB]

Brahiewahiewa schreef op woensdag 21 februari 2018 @ 05:58:
Jullie denken veeel te moeilijk. D'r is gewoon één source en meerdere clients en kennelijk kan die source niet met meerdere clients omgaan. Om dat succesvol te kunnen frauderen laat je die client slechts op één machine draaien draaien (de server) en z'n output uitspugen naar html. Alle andere clients connecten naar die html-stream

En zelfs dat is nog te moeilijk; waarom naar html? Ik snap ook niet waarom er boven wordt gemeld dat je het protocol moet snappen of waarom een oplossing afhankelijk is van dit protocol.

Wat er gezocht wordt is iets wat alle bytes die ontvangen worden 1 op 1 doorstuurt naar alle clients die hij zelf heeft.

Ik denk ook niet dat je dit gaat vinden omdat dit een vrij unieke situatie is (unidirectioneel over tcp). Is dit nodig voor in een productie omgeving of tijdelijk?

[unezra]

Brahiewahiewa schreef op woensdag 21 februari 2018 @ 05:58:
Jullie denken veeel te moeilijk. D'r is gewoon één source en meerdere clients en kennelijk kan die source niet met meerdere clients omgaan. Om dat succesvol te kunnen frauderen laat je die client slechts op één machine draaien draaien (de server) en z'n output uitspugen naar html. Alle andere clients connecten naar die html-stream

Dan moet die source dus worden aangepast dat 'ie dat wel kan.
"Works as designed."

Dit klinkt niet als iets dat je met een vieze hack zoals TS en collega vragen moet willen oplossen.

[Gomez12]

MerijnB schreef op woensdag 21 februari 2018 @ 07:07:
[...]
En zelfs dat is nog te moeilijk; waarom naar html? Ik snap ook niet waarom er boven wordt gemeld dat je het protocol moet snappen of waarom een oplossing afhankelijk is van dit protocol.

Wat er gezocht wordt is iets wat alle bytes die ontvangen worden 1 op 1 doorstuurt naar alle clients die hij zelf heeft.

De reden dat het applicatieprotocol afhankelijk is is omdat op tcp niveau alle bytes ook ack etc bevatten die je weer niet wilt doorsturen.
Je moet het ook niet moeilijker maken dan het is, zoals ik al zeg in elke scripttaal zijn idd alle zinnige bytes (dus op applicatieprotocol niveau en niet op tcp-niveau) gewoon door te zetten, en dat hoeft helemaal niet zo spannend te zijn omdat het waarschijnlijk een extreem simpele applicatieprotocol is (ik gok dat je enkel een encoding hoeft te specificeren en dat dat zo ongeveer je hele applicatie-protocol is omdat de rest door de tcp-stack afgehandeld wordt waar je niets mee te maken wilt hebben)

Ik denk ook niet dat je dit gaat vinden omdat dit een vrij unieke situatie is (unidirectioneel over tcp).

Het is geen unieke situatie, het is gewoon een verkeerd omschreven probleem. Het is met 99% zekerheid geen unidirectioneel verkeer over tcp (want dat is extreem moeilijk om voor elkaar te krijgen en je hebt er direct een alternatief voor in de vorm van udp).
Het tcp-verkeer zal gewoon bi-directioneel zijn zoals al het tcp-verkeer.

Het probleem is hier puur en alleen de probleemomschrijving die gewoon een shitload aan interessante termen bevat die voor TS simpelweg niet van toepassing zijn.

[MerijnB]

Gomez12 schreef op woensdag 21 februari 2018 @ 10:10:
[...]

De reden dat het applicatieprotocol afhankelijk is is omdat op tcp niveau alle bytes ook ack etc bevatten die je weer niet wilt doorsturen.
Je moet het ook niet moeilijker maken dan het is, zoals ik al zeg in elke scripttaal zijn idd alle zinnige bytes (dus op applicatieprotocol niveau en niet op tcp-niveau) gewoon door te zetten, en dat hoeft helemaal niet zo spannend te zijn omdat het waarschijnlijk een extreem simpele applicatieprotocol is (ik gok dat je enkel een encoding hoeft te specificeren en dat dat zo ongeveer je hele applicatie-protocol is omdat de rest door de tcp-stack afgehandeld wordt waar je niets mee te maken wilt hebben)


[...]

Het is geen unieke situatie, het is gewoon een verkeerd omschreven probleem. Het is met 99% zekerheid geen unidirectioneel verkeer over tcp (want dat is extreem moeilijk om voor elkaar te krijgen en je hebt er direct een alternatief voor in de vorm van udp).
Het tcp-verkeer zal gewoon bi-directioneel zijn zoals al het tcp-verkeer.

Het probleem is hier puur en alleen de probleemomschrijving die gewoon een shitload aan interessante termen bevat die voor TS simpelweg niet van toepassing zijn.

TS heeft een hoop dingen een beetje vreemd omschreven, maar volgens mij is het harstikke duidelijk dat dit zich allemaal op applicatieniveau speelt.

Dan heb je dus niet te maken met acks, is het heel goed mogelijk dat het verkeer unidirectioneel is en is het voor een appje helemaal niet nodig iets te snappen van de data die gerelayed moet worden. Encoding is dus ook niet van toepassing; gewoon alle data 1 op 1 doorsturen (op applicatie niveau dus). Sowieso suggereert encoding dat het om niet binaire data gaat; zelfs dat is niet bekend (en niet interessant).

[ Voor 3% gewijzigd door MerijnB op 21-02-2018 10:40 ]

[unezra]

@MerijnB Leuk. Maar waarom zo'n kludge als TS gewoon de developer moet aanspreken dat 'ie die T splitsing nodig heeft? Dit is een developer die niet snapt hoe het werkt of TS die een onredelijke eis heeft.

Je moet zoiets op applicatieniveau oplossen, de source moet het doen. Niet allerlei hacks er tussen frutsen die uiteindelijk onbeheersbaar zijn. (Tenzij het om een one-time-job gaat maar ik krijg de indruk dat dit permanent is.)

[MerijnB]

unezra schreef op woensdag 21 februari 2018 @ 11:08:
@MerijnB Leuk. Maar waarom zo'n kludge als TS gewoon de developer moet aanspreken dat 'ie die T splitsing nodig heeft? Dit is een developer die niet snapt hoe het werkt of TS die een onredelijke eis heeft.

Je moet zoiets op applicatieniveau oplossen, de source moet het doen. Niet allerlei hacks er tussen frutsen die uiteindelijk onbeheersbaar zijn. (Tenzij het om een one-time-job gaat maar ik krijg de indruk dat dit permanent is.)

Dat moet je aan TS vragen, misschien kan of wil de originele ontwikkelaar dit niet; vandaar ook mijn vraag aan TS rond 7 uur vanmorgen.

Soms kan het niet zoals het moet, maar moet het zoals het kan

[unezra]

MerijnB schreef op woensdag 21 februari 2018 @ 11:10:
[...]
Dat moet je aan TS vragen, misschien kan of wil de originele ontwikkelaar dit niet; vandaar ook mijn vraag aan TS rond 7 uur vanmorgen.

”Ik kan niet” ligt op het kerkhof. ”Ik wil niet” ligt er naast.

Ik heb vaker te maken met developers, met zoiets komen ze bij mij niet heel ver zeg maar.
(En als sysadmin heb ik weinig subtiele tools tot mijn beschikking om developers te laten doen wat ik zeg.)

Soms kan het niet zoals het moet, maar moet het zoals het kan

Ja, maar shit oplossen met vieze hacks is eigenlijk zelden een goede oplossing en er is niets zo permanent als een tijdelijke oplossing.

[MerijnB]

unezra schreef op woensdag 21 februari 2018 @ 11:50:
[...]


”Ik kan niet” ligt op het kerkhof. ”Ik wil niet” ligt er naast.

Ik heb vaker te maken met developers, met zoiets komen ze bij mij niet heel ver zeg maar.
(En als sysadmin heb ik weinig subtiele tools tot mijn beschikking om developers te laten doen wat ik zeg.)


[...]


Ja, maar shit oplossen met vieze hacks is eigenlijk zelden een goede oplossing en er is niets zo permanent als een tijdelijke oplossing.

Zolang we niets weten over het hoe en waarom blijft het gissen. Ik ben overigens wel benieuwd naar je nieuwe subtiele tools.

[unezra]

MerijnB schreef op woensdag 21 februari 2018 @ 11:56:
[...]


Zolang we niets weten over het hoe en waarom blijft het gissen. Ik ben overigens wel benieuwd naar je nieuwe subtiele tools.

"Je werkt zoals ik wil, volgens onze procedures en volgens onze wensen en eisen, anders installeer ik je shit niet op onze omgeving."

(Ofwel, het spreekwoordelijke eind hout.)

[MerijnB]

unezra schreef op woensdag 21 februari 2018 @ 11:58:
[...]


"Je werkt zoals ik wil, volgens onze procedures en volgens onze wensen en eisen, anders installeer ik je shit niet op onze omgeving."

(Ofwel, het spreekwoordelijke eind hout.)

Laat ik het erop houden dat ik blij ben dat ik als ontwikkelaar lekker zelf mijn omgeving in kan richten

Beetje jammer als een systeembeheerder die totaal geen inzicht in mijn problematiek heeft met een eind hout zijn zin wil krijgen ...

[michaelbar]

Hi allen,

Dank jullie vriendelijk voor al jullie hulp, ik kan inderdaad niet goed programmeren (en kon geen dev vinden die mij hier mee wilde helpen), ben bezig Python te leren, kan enigzins php...

Ik heb het orignele post een beetje aangepast aan de hand van veel besproken informatie hier. Wat evt. onduidelijk was was dat ik niet expliciet een verschil aanduide tussen de 'server/client end points' mbt. de 'connecties (TCP)' en de 'data-stream (applicatie)'.

Wat betreft ACKs die inderdaad terug gestuurd worden naar de tool, maakt verder niks uit, die mag de tool gebruiken, maar die hoeven niet verder naar 'boven' terug naar de source (zodoende mogen ze daar ge-terminate worden).

Haproxy is enkel voor linux...

Enige andere tools die in jullie op komen?

Alvorens dank.

[ Voor 3% gewijzigd door michaelbar op 21-02-2018 12:12 ]

[unezra]

MerijnB schreef op woensdag 21 februari 2018 @ 12:08:
[...]
Laat ik het erop houden dat ik blij ben dat ik als ontwikkelaar lekker zelf mijn omgeving in kan richten

Zolang het je eigen omgeving is die volledig is afgeschermd van de omgeving waar mijn gebruikers op zitten en systemen op draaien best. Zodra je iets bakt dat op mijn omgeving moet draaien, bepaal ik de regels.

Beetje jammer als een systeembeheerder die totaal geen inzicht in mijn problematiek heeft met een eind hout zijn zin wil krijgen ...

Het probleem is juist vaak dat developers echt geen flauwe notie hebben van de wereld buiten hun applicatie. Gechargeerd en positieve uitzonderingen daargelaten (of ik heb gewoon veel pech met developers), maar over het algemeen is het maar goed dat de developer developt en de systeemverantwoordelijkheden paal en perk stellen aan de idiotie waar developers soms mee komen.

Ik heb wel wat voorbeelden zeg maar waar een developer iets wilde, dat code-technisch gezien misschien helemaal niet zo onzinnig was, maar waarbij totaal geen rekening werd gehouden met de omgeving waarop het moest draaien.

(Een developer die een applicatie schrijft die het perfect doet, op zijn 8-core doos met NVME, met 1 gebruiker, maar totaal faalt in een omgeving met SAN, meerdere servers, meerdere gebruikers en een netwerk. Om maar een willekeurig voorbeeld te noemen.)

[MerijnB]

unezra schreef op woensdag 21 februari 2018 @ 12:12:
[...]


Zolang het je eigen omgeving is die volledig is afgeschermd van de omgeving waar mijn gebruikers op zitten en systemen op draaien best. Zodra je iets bakt dat op mijn omgeving moet draaien, bepaal ik de regels.


[...]


Het probleem is juist vaak dat developers echt geen flauwe notie hebben van de wereld buiten hun applicatie. Gechargeerd en positieve uitzonderingen daargelaten (of ik heb gewoon veel pech met developers), maar over het algemeen is het maar goed dat de developer developt en de systeemverantwoordelijkheden paal en perk stellen aan de idiotie waar developers soms mee komen.

Ik heb wel wat voorbeelden zeg maar waar een developer iets wilde, dat code-technisch gezien misschien helemaal niet zo onzinnig was, maar waarbij totaal geen rekening werd gehouden met de omgeving waarop het moest draaien.

(Een developer die een applicatie schrijft die het perfect doet, op zijn 8-core doos met NVME, met 1 gebruiker, maar totaal faalt in een omgeving met SAN, meerdere servers, meerdere gebruikers en een netwerk. Om maar een willekeurig voorbeeld te noemen.)

Laten we het op twee kanten van hetzelfde hek houden

[MerijnB]

michaelbar schreef op woensdag 21 februari 2018 @ 12:10:
Hi allen,

Dank jullie vriendelijk voor al jullie hulp, ik kan inderdaad niet goed programmeren (en kon geen dev vinden die mij hier mee wilde helpen), ben bezig Python te leren, kan enigzins php...

Ik heb het orignele post een beetje aangepast aan de hand van veel besproken informatie hier. Wat evt. onduidelijk was was dat ik niet expliciet een verschil aanduide tussen de 'server/client end points' mbt. de 'connecties (TCP)' en de 'data-stream (applicatie)'.

Wat betreft ACKs die inderdaad terug gestuurd worden naar de tool, maakt verder niks uit, die mag de tool gebruiken, maar die hoeven niet verder naar 'boven' terug naar de source (zodoende mogen ze daar ge-terminate worden).

Haproxy is enkel voor linux...

Enige andere tools die in jullie op komen?

Alvorens dank.

Kom je nog even terug op de vraag die ik vanmorgen rond 7:00 stelde?

[laurens0619]

Ik vraag mij af of dit je probleem gaat oplossen maar rinetd zou moeten doen waar jij naar op zoek bent. Ik besef mij net wel dat ik oud aan het worden ben aangezien de tool uit het win98 tijdperk komt maar zal waarsch nog wel werken

Edit: of je pakt zoiets geschreven in go https://github.com/adhocteam/tcpproxy

[ Voor 14% gewijzigd door laurens0619 op 21-02-2018 12:20 ]

[MerijnB]

laurens0619 schreef op woensdag 21 februari 2018 @ 12:19:
Ik vraag mij af of dit je probleem gaat oplossen maar rinetd zou moeten doen waar jij naar op zoek bent. Ik besef mij net wel dat ik oud aan het worden ben aangezien de tool uit het win98 tijdperk komt maar zal waarsch nog wel werken

Edit: of je pakt zoiets geschreven in go https://github.com/adhocteam/tcpproxy

Volgens mij redirect die alleen en dupliceert niet.

[laurens0619]

MerijnB schreef op woensdag 21 februari 2018 @ 12:22:
[...]


Volgens mij redirect die alleen en dupliceert niet.

Klopt helemaal, ik heb alleen moeite om het probleem van de ts te doorgronden. Heeft de oorspronkelijke service wellicht een ip restrictie? Dan zou deze tool wel helpen.

@michaelbar
Voor alle andere gevallen kun je met tcp connecties dit probleem per definitie niet met een generieke tool oplossen die niets van de applicatie logica begrijpt. Ergena zal door de tool namelijk een handshake met de client gesimuleerd worden en bepaalde response wel geforwarded/gecached/doorgestuurd moeten worden.

[MerijnB]

laurens0619 schreef op woensdag 21 februari 2018 @ 12:27:
[...]

Klopt helemaal, ik heb alleen moeite om het probleem van de ts te doorgronden. Heeft de oorspronkelijke service wellicht een ip restrictie? Dan zou deze tool wel helpen.
Voor alle andere gevallen kun je met tcp connecties dit probleem per definitie niet met een generieke tool oplossen die niets van de applicatie logica begrijpt. Ergena zal door de tool namelijk een handshake met de client gesimuleerd worden en bepaalde response wel geforwarded/gecached/doorgestuurd moeten worden.

Zover ik begrijp geen ip restricties, alleen staat de server maar 1 client toe en zijn er meer nodig. Aangezien er geen sprake is van bidirectionele communcatie (op applicatie niveau) wordt er gezocht naar iets wat deze data doorstuurt naar meerdere clients. Vandaar is er geen begrip van applicatie logica nodig, er zijn geen handshakes etc.... denk ik te begrijpen

[michaelbar]

MerijnB schreef op woensdag 21 februari 2018 @ 07:07:
...Is dit nodig voor in een productie omgeving of tijdelijk?

Beste @MerijnB, dit gaat uit eindelijk om een productie omgeving inderdaad.

[laurens0619]

MerijnB schreef op woensdag 21 februari 2018 @ 12:29:
[...]


Zover ik begrijp geen ip restricties, alleen staat de server maar 1 client toe en zijn er meer nodig. Aangezien er geen sprake is van bidirectionele communcatie (op applicatie niveau) wordt er gezocht naar iets wat deze data doorstuurt naar meerdere clients. Vandaar is er geen begrip van applicatie logica nodig, er zijn geen handshakes etc.... denk ik te begrijpen

Een ip restrictie kan natuurlijk ook 1 acieve sessie van een ip restrictie zijn (willekeurig welk ip adres dat is).

Mbt je ander comment zit ik toch meer op 1 lijn met @Gomez12, de benodigde applicatie logica is minimaal maar je hebt toch iets nodig

[MerijnB]

laurens0619 schreef op woensdag 21 februari 2018 @ 12:37:
[...]
de benodigde applicatie logica is minimaal maar je hebt toch iets nodig

ik ben (gegeven wat TS tot nu toe aan informatie heeft gegeven) wel benieuwd wat dat is dan.

[BCC]

Zo veel vragen 😀😬

[unezra]

michaelbar schreef op woensdag 21 februari 2018 @ 12:33:
[...]


Beste @MerijnB, dit gaat uit eindelijk om een productie omgeving inderdaad.

Dan dus het probleem bij de bron oplossen en niet met een kludge.

Ofwel: Bel je developer.

[laurens0619]

MerijnB schreef op woensdag 21 februari 2018 @ 12:38:
[...]


ik ben (gegeven wat TS tot nu toe aan informatie heeft gegeven) wel benieuwd wat dat is dan.

Stel je hebt: backend, client1, client2 en duplicator

Als client1 verbinding maakt met duplicator wil je eigenlijk deze data 1op1 door duplicator doorzetten naar backend. J
Een backend gaat nl uit zichzelf data sturen naar een adres, daar moet een bepaalde logica inzitten

Als client2 verbinding maakt wil je deze aanvraag niet doorzetten maar de gesimuleerde response teruggeven (die gecached is uit sessie van client1) omdat het anders weer als 2e request gezien wordt.

Je moet dus weten wanneer filteren en wanneer dupliceren. Hoe zou jij dit anders programmere met pseudologica als je alleen weet dat het tcp is?

[MerijnB]

laurens0619 schreef op woensdag 21 februari 2018 @ 12:45:
[...]

Stel je hebt: backend, client1, client2 en duplicator

Als client1 verbinding maakt met duplicator wil je eigenlijk deze data 1op1 door duplicator doorzetten naar backend. J
Een backend gaat nl uit zichzelf data sturen naar een adres, daar moet een bepaalde logica inzitten

Als client2 verbinding maakt wil je deze aanvraag niet doorzetten maar de gesimuleerde response teruggeven (die gecached is uit sessie van client1) omdat het anders weer als 2e request gezien wordt.

Je moet dus weten wanneer filteren en wanneer dupliceren. Hoe zou jij dit anders programmere met pseudologica als je alleen weet dat het tcp is?

Bij de probleemstelling van TS begrijp ik dat de backend alleen data verstuurd naar de client en de client niet terug.

Dus: duplicator verbind met backend
Client 1 verbind met duplicator
Client 2 verbind met duplicator

Alle data die duplicator van backend ontvangt wordt 1 op 1 doorgestuurd naar alle verbonden clients.
Geen handshakes etc; als een client niet verbonden was toen de backend iets stuurde, en de duplicator dat doorstuurde naar verbonden clients is dat het probleem van die client.

[laurens0619]

MerijnB schreef op woensdag 21 februari 2018 @ 12:49:
[...]


Bij de probleemstelling van TS begrijp ik dat de backend alleen data verstuurd naar de client en de client niet terug.

Dus: duplicator verbind met backend
Client 1 verbind met duplicator
Client 2 verbind met duplicator

Alle data die duplicator van backend ontvangt wordt 1 op 1 doorgestuurd naar alle verbonden clients.
Geen handshakes etc; als een client niet verbonden was toen de backend iets stuurde, en de duplicator dat doorstuurde naar verbonden clients is dat het probleem van die client.

Een backend kan per definitie niet alleen data versturen naar de client (dan zouden de rollen namelijk andersom zijn), de client initieert het request om data te ontvangen.

Maar wat is dan de definitie van data? Een simpele tcp response kan vanalles zijn, daarom moet je weten wanneer het applicatiedata betreft

[Webaccess]

Ik begrijp de vraag en de reacties niet helemaal maar kunnen we de aanname doen dat alleen ontvangen voldoende is. Als ik radio wil luisteren dan moet ik deze op een zender zetten (initiatie) maar iedereen in de kamer kan hier vervolgens naar luisteren zonder hier maar iets voor te doen (initiatie) of er iets van te vinden (handshake / acknowlegde / ..)

Misschien dat het onderstaande je hierbij verder kan helpen (google: Duplicatie IP Package)

https://devcentral.f5.com...dp-tcp-packet-duplication
https://www.dcbnet.com/datasheet/pr6602ds.html
codelectron.com/stone-an-awesome-packet-repeater-tool-that-will-save-your-day/

[MerijnB]

laurens0619 schreef op woensdag 21 februari 2018 @ 12:55:
[...]

Een backend kan per definitie niet alleen data versturen naar de client (dan zouden de rollen namelijk andersom zijn), de client initieert het request om data te ontvangen.

Dit is niet waar, wie client of server is heeft totaal geen invloed wie data stuurt (op applicatielaag).

Maar wat is dan de definitie van data? Een simpele tcp response kan vanalles zijn, daarom moet je weten wanneer het applicatiedata betreft

Alles wat je op applicatielaag krijgt, een tcp response is dat dus niet.

[laurens0619]

MerijnB schreef op woensdag 21 februari 2018 @ 13:03:
[...]

Dit is niet waar, wie client of server is heeft totaal geen invloed wie data stuurt (op applicatielaag).


[...]

Alles wat je op applicatielaag krijgt, een tcp response is dat dus niet.

Ja maar de initiele vraag voor data zit ook in deze laag, die wil je dan filteren lijkt me?

Je klinkt alsof het ook niet heel complex is om te ontwikkelen, misschien kun je een paar regels go/python/nodejs uitwerken als poc?

[ Voor 14% gewijzigd door laurens0619 op 21-02-2018 13:16 ]

[Gomez12]

MerijnB schreef op woensdag 21 februari 2018 @ 12:38:
[...]


ik ben (gegeven wat TS tot nu toe aan informatie heeft gegeven) wel benieuwd wat dat is dan.

Een initiator.

Het is een heel aparte constructie als een server blindelings maar continue data gaat pompen naar een ip-adres zonder dat er een start-signaal oid gegeven is of enig akkoord over TCP, over UDP is dit de gewoonste zaak van de wereld maar daar heeft TS het niet over.

Wat er praktisch zal gebeuren is dat de client gewoon een eerste handshake doet en vraagt om data en dat de server daarna data gaat pompen over een stream en TS zal die stream willen opvangen op meerdere eindpunten. Zonder die eerste handshake zal er geen stream opgezet worden.

En tja, puur theoretisch zou je een situatie kunnen bouwen dat je eerst de client opstart en dan razendsnel die afsluit na het versturen van de handshake (anders blijft de client de poort in gebruik houden) en dan razendsnel een haproxy ertussen douwen die de bytes uit de stream gaat verdelen.
Alleen veel plezier met deze timing, theoretisch kan het praktisch niet echt...

[MerijnB]

Gomez12 schreef op woensdag 21 februari 2018 @ 13:15:
[...]

Een initiator.

Het is een heel aparte constructie als een server blindelings maar continue data gaat pompen naar een ip-adres zonder dat er een start-signaal oid gegeven is of enig akkoord over TCP, over UDP is dit de gewoonste zaak van de wereld maar daar heeft TS het niet over.

Wat er praktisch zal gebeuren is dat de client gewoon een eerste handshake doet en vraagt om data en dat de server daarna data gaat pompen over een stream en TS zal die stream willen opvangen op meerdere eindpunten. Zonder die eerste handshake zal er geen stream opgezet worden.

En tja, puur theoretisch zou je een situatie kunnen bouwen dat je eerst de client opstart en dan razendsnel die afsluit na het versturen van de handshake (anders blijft de client de poort in gebruik houden) en dan razendsnel een haproxy ertussen douwen die de bytes uit de stream gaat verdelen.
Alleen veel plezier met deze timing, theoretisch kan het praktisch niet echt...

Sorry, ik kan me hier totaal niet in vinden. We weten niets over de serverapplicatie en wat voor dataprotocol (applicatielaag) daar gebruikt wordt. Natuurlijk zou het kunnen dat die server alleen data stuurt. Het is helemaal geen vereiste dat een client eerst iets stuurt voordat een server iets op kan sturen; TS is er blijkbaar van overtuigd dat dit niet nodig is.

Puur hypothetisch, stel je kunt een socket verbinding opzetten naar een gps ontvanger die elke seconde z'n huidige positie doorgeeft.

[MerijnB]

laurens0619 schreef op woensdag 21 februari 2018 @ 13:14:
[...]

Ja maar de initiele vraag voor data zit ook in deze laag, die wil je dan filteren lijkt me?

Je klinkt alsof het ook niet heel complex is om te ontwikkelen, misschien kun je een paar regels go/python/nodejs uitwerken als poc?

Waarom spreek je over een initieele vraag? TS geeft toch aan dat die er niet is?

[johnkeates]

Kan dit niet gewoon met NAT? Server weet niks over de clients, ziet 1 IP, meerdere SRC ports. Problem solved?

Je kan ook niet met vieze hacks TCP naar je hand proberen te zetten, want dat zou aan de server kant dan ook moeten gebeuren en dat kan nu blijkbaar niet.

Laat ik het zo stellen: als het niet met NAT kan, en niet met een reverse proxy, dan moet je het gewoon niet doen.

[ Voor 18% gewijzigd door johnkeates op 21-02-2018 13:47 ]

[Orion84]

MerijnB schreef op woensdag 21 februari 2018 @ 13:21:
[...]


Waarom spreek je over een initieele vraag? TS geeft toch aan dat die er niet is?

Wellicht dat er geen expliciete vraag is zoals bijvoorbeeld een HTTP GET request bij webserver/client communicatie, maar dan is er nog altijd het opzetten van de TCP verbinding wat geinitieerd wordt door de client.

Je kan niet zomaar data naar een TCP client sturen, als die client gebouwd is om zelf de connectie te initiëren en daarna pas data te ontvangen. Je zult in de 'proxy' of hoe je het ding wat TS wil bouwen ook wilt noemen, dus logica moeten hebben om aan de ene kant zelf een verbinding met de server te initiëren, als ware de proxy een client en aan de andere kant verbindingen van echte clients te accepteren en vervolgens de data die ontvangen wordt van de server door te zetten naar de clients.

Dat ga je dus nooit oplossen met een hub of port mirroring of wat dan ook. De daadwerkelijke clients kunnen namelijk pas data ontvangen nadat ze zelf een verbinding met een server hebben geïnitieerd.

[Gomez12]

MerijnB schreef op woensdag 21 februari 2018 @ 13:20:
[...]
Het is helemaal geen vereiste dat een client eerst iets stuurt voordat een server iets op kan sturen; TS is er blijkbaar van overtuigd dat dit niet nodig is.

Dit is puur cherrypicken naar wat je wilt.

TS is van veel meer dingen overtuigd die complete onzin zijn gebleken in dit topic alleen al.
Ik volg dan gewoon de standaard logica hoe iets normaal gesproken zou werken en ga niet zitten cherry-picken uit rare dingen die een TS zegt.

Zie ook de nieuwe TS, waar opeens connecting clients zijn, waar opeens de tool "connecties toe moet kunnen laten". Klinkt allemaal verdacht veel als handshakes en bi-directioneel verkeer.

Orion84 schreef op woensdag 21 februari 2018 @ 13:52:
[...]
Wellicht dat er geen expliciete vraag is zoals bijvoorbeeld een HTTP GET request bij webserver/client communicatie, maar dan is er nog altijd het opzetten van de TCP verbinding wat geinitieerd wordt door de client.

Puur theoretisch is dit niet nodig hoor, je server kan gewoon in een eeuwige loop proberen tcp-verbindingen op te bouwen met een client die helemaal niet online is. Alleen het is een compleet inefficiente aanpak.

Maar dit is als ik het goed begrijp wel waar MerijnB vanuit wil gaan. Een server die via TCP zelf connecties opzet, alle foutmeldingen vanuit TCP negerend en gewoon keihard doorbeuken.

[ Voor 32% gewijzigd door Gomez12 op 21-02-2018 13:57 ]

[MerijnB]

Gomez12 schreef op woensdag 21 februari 2018 @ 13:53:
[...]

Dit is puur cherrypicken naar wat je wilt.

TS is van veel meer dingen overtuigd die complete onzin zijn gebleken in dit topic alleen al.
Ik volg dan gewoon de standaard logica hoe iets normaal gesproken zou werken en ga niet zitten cherry-picken uit rare dingen die een TS zegt.

Knap dat jij weet hoe deze applicatie z'n data verstuurd zonder dat je weet wat voor app het is, en cherry picking... really?

Zie ook de nieuwe TS, waar opeens connecting clients zijn, waar opeens de tool "connecties toe moet kunnen laten". Klinkt allemaal verdacht veel als handshakes en bi-directioneel verkeer.


[...]

Puur theoretisch is dit niet nodig hoor, je server kan gewoon in een eeuwige loop proberen tcp-verbindingen op te bouwen met een client die helemaal niet online is. Alleen het is een compleet inefficiente aanpak.

Maar dit is als ik het goed begrijp wel waar MerijnB vanuit wil gaan. Een server die via TCP zelf connecties opzet, alle foutmeldingen vanuit TCP negerend en gewoon keihard doorbeuken.

Een server die een verbinding opbouwt met een client? Meestal gaat dat andersom. Ik snap niet precies wat je hier bedoelt.

[laurens0619]

Gomez12 schreef op woensdag 21 februari 2018 @ 13:53:
[...]

Dit is puur cherrypicken naar wat je wilt.

TS is van veel meer dingen overtuigd die complete onzin zijn gebleken in dit topic alleen al.
Ik volg dan gewoon de standaard logica hoe iets normaal gesproken zou werken en ga niet zitten cherry-picken uit rare dingen die een TS zegt.

Zie ook de nieuwe TS, waar opeens connecting clients zijn, waar opeens de tool "connecties toe moet kunnen laten". Klinkt allemaal verdacht veel als handshakes en bi-directioneel verkeer.


[...]

Puur theoretisch is dit niet nodig hoor, je server kan gewoon in een eeuwige loop proberen tcp-verbindingen op te bouwen met een client die helemaal niet online is. Alleen het is een compleet inefficiente aanpak.

Maar dit is als ik het goed begrijp wel waar MerijnB vanuit wil gaan. Een server die via TCP zelf connecties opzet, alle foutmeldingen vanuit TCP negerend en gewoon keihard doorbeuken.

Eens dat de initiatie niet in de applicatie layer hoeft te zitten, tcp request is inderdaad ook voldoende.

Mbt je 2e stuk: dit is toch alleen mogelijk als je applicatie hardcoded richting een aantal ip adressen gaat sturen en maakt dit hem dan niet eerder een client dan een server?

[MerijnB]

Orion84 schreef op woensdag 21 februari 2018 @ 13:52:
[...]
Je kan niet zomaar data naar een TCP client sturen, als die client gebouwd is om zelf de connectie te initiëren en daarna pas data te ontvangen.

Uiteraard kun je geen data versturen naar een client die niet verbonden is, maar dat vraag TS toch ook niet?

Je zult in de 'proxy' of hoe je het ding wat TS wil bouwen ook wilt noemen, dus logica moeten hebben om aan de ene kant zelf een verbinding met de server te initiëren, als ware de proxy een client en aan de andere kant verbindingen van echte clients te accepteren en vervolgens de data die ontvangen wordt van de server door te zetten naar de clients.

Precies dit! Dit betreft dus geen logica mbt data protocol wat de applicatie gebruikt.

[laurens0619]

MerijnB schreef op woensdag 21 februari 2018 @ 14:04:
[...]

Uiteraard kun je geen data versturen naar een client die niet verbonden is, maar dat vraag TS toch ook niet?


[...]


Precies dit! Dit betreft dus geen logica mbt data protocol wat de applicatie gebruikt.

Ik heb nog wat zitten nadenken (en wat testjes in nodejs gedaan) en bang ben dat ik mijn standpunt toch wat moet verzwakken. Als het applicatieprotocol meewerkt (lees bv continue data sturen na openen socket) dan is dit vanuit theoreotisch standpunt inderdaad toch prima mogelijk. (maw, you were right, I was wrong )

In de praktijk kom ik soortgelijke implementaties eigenlijk nooit tegen (muw je gps voorbeeld die mij aan het denken zette:)) maar dat is in de theoretische vraagstelling inderdaad niet relevant.

[ Voor 15% gewijzigd door laurens0619 op 21-02-2018 16:35 ]

[MerijnB]

laurens0619 schreef op woensdag 21 februari 2018 @ 16:24:
[...]

Ik heb nog wat zitten nadenken (en wat testjes in nodejs gedaan) en bang ben dat ik mijn standpunt toch wat moet verzwakken. Als het applicatieprotocol meewerkt (lees bv continue data sturen na openen socket) dan is dit vanuit theoreotisch standpunt inderdaad toch prima mogelijk. (maw, you were right, I was wrong )

In de praktijk kom ik soortgelijke implementaties eigenlijk nooit tegen (muw je gps voorbeeld die mij aan het denken zette:)) maar dat is in de theoretische vraagstelling inderdaad niet relevant.

Ik ben ondertussen erg benieuwd wat over wat voor toepassing TS het heeft, en of we het inderdaad bij het rechte eind hebben

[michaelbar]

Orion84 schreef op woensdag 21 februari 2018 @ 13:52:
[...]

Wellicht dat er geen expliciete vraag is zoals bijvoorbeeld een HTTP GET request bij webserver/client communicatie, maar dan is er nog altijd het opzetten van de TCP verbinding wat geinitieerd wordt door de client.

Je kan niet zomaar data naar een TCP client sturen, als die client gebouwd is om zelf de connectie te initiëren en daarna pas data te ontvangen. Je zult in de 'proxy' of hoe je het ding wat TS wil bouwen ook wilt noemen, dus logica moeten hebben om aan de ene kant zelf een verbinding met de server te initiëren, als ware de proxy een client en aan de andere kant verbindingen van echte clients te accepteren en vervolgens de data die ontvangen wordt van de server door te zetten naar de clients.

Dat ga je dus nooit oplossen met een hub of port mirroring of wat dan ook. De daadwerkelijke clients kunnen namelijk pas data ontvangen nadat ze zelf een verbinding met een server hebben geïnitieerd.

Beste allen,

Wat hier beschreven wordt, is precies wat ik bedoel.

Waar ik het met name over heb, is dat jullie eigenlijk 2 dingen volledig apart moeten zien.

1. We maken met een proxy achtige service een connectie aan de originating source, die stormt binnen, en sturen we nergens heen (the void), gewoon vertellen tegen die source, "ja, kom goed binnen, blijf maar sturen" (dat is bi-directional en kan met TCP).

2. Vervolgens heeft de proxy service de mogelijkheid tot het instellen van een listener (server) die braaf staat te luisteren op poort XXXX.

Daarna ga ik met mijn Putty client vanaf een andere PC, connecten aan die proxy (op poort XXXX) en "Heuy, guys, er komt een connectie binnen, we kunnen nu onze feed doorsturen naar hun ipv. the void (want we hebben alle nodige informatie om een connectie terug op te maken, dus laat TCP maar een nieuwe connectie maken naar die client, dan kunnen we poort XXXX weer gereed maken voor een eerst volgende beller)". En dan wordt er nog even code uitgevoerd om de inbound source feed door te sluizen aan de bellende client, en is alles weer ready and waiting.

En een paar uur later... "Heuy, guys, er komt een connectie binnen, we kunnen nu onze feed ook nog eens doorsturen naar hun ipv. alleen naar 'client 1' (want we hebben alle nodige informatie om een connectie terug op te maken, dus laat TCP maar een nieuwe connectie maken naar die client, dan kunnen we poort XXXX weer gereed maken voor een eerst volgende beller)". En dan wordt er nog even code uitgevoerd om de inbound source feed door te sluizen aan de nieuwe bellende client, en is alles weer ready and waiting.

En zo voort, en zo voort...

Als deze tool vervolgens ook een logger kan zijn, en die files nog met LMZA2 kan compressen... maar dat lukt mij anders ook nog wel dmv. batch/powershell en "Task Scheduler"

Wederom, ben blij dat jullie allemaal veel kennis hier aan de hand van op doen, maar dit hoort een simpel iets te zijn voor de gemiddelde tweaker.

Dus.... welke tool kan ik hiervoor gebruiken?

Thanks guys

[BCC]

Ik ben bang dat je een programmeur moet regelen die dit "even" voor je elkaar zet met een programmeertaal naar keuze.

[zzattack]

Ik gebruik voor vrijwel precies deze requirements een zelfgemaakt tooltje. Vaak is het een debugging aid en hoeft het niet maandenlang reliable en onaangeraakt te draaien dus het is gui based. Een kant-en-klare oplossing zul je niet gauw vinden ben ik bang.

[|sWORDs|]

michaelbar schreef op donderdag 22 februari 2018 @ 10:58:
[...]


Beste allen,

Wat hier beschreven wordt, is precies wat ik bedoel.

Waar ik het met name over heb, is dat jullie eigenlijk 2 dingen volledig apart moeten zien.

1. We maken met een proxy achtige service een connectie aan de originating source, die stormt binnen, en sturen we nergens heen (the void), gewoon vertellen tegen die source, "ja, kom goed binnen, blijf maar sturen" (dat is bi-directional en kan met TCP).

2. Vervolgens heeft de proxy service de mogelijkheid tot het instellen van een listener (server) die braaf staat te luisteren op poort XXXX.

Daarna ga ik met mijn Putty client vanaf een andere PC, connecten aan die proxy (op poort XXXX) en "Heuy, guys, er komt een connectie binnen, we kunnen nu onze feed doorsturen naar hun ipv. the void (want we hebben alle nodige informatie om een connectie terug op te maken, dus laat TCP maar een nieuwe connectie maken naar die client, dan kunnen we poort XXXX weer gereed maken voor een eerst volgende beller)". En dan wordt er nog even code uitgevoerd om de inbound source feed door te sluizen aan de bellende client, en is alles weer ready and waiting.

En een paar uur later... "Heuy, guys, er komt een connectie binnen, we kunnen nu onze feed ook nog eens doorsturen naar hun ipv. alleen naar 'client 1' (want we hebben alle nodige informatie om een connectie terug op te maken, dus laat TCP maar een nieuwe connectie maken naar die client, dan kunnen we poort XXXX weer gereed maken voor een eerst volgende beller)". En dan wordt er nog even code uitgevoerd om de inbound source feed door te sluizen aan de nieuwe bellende client, en is alles weer ready and waiting.

En zo voort, en zo voort...

Als deze tool vervolgens ook een logger kan zijn, en die files nog met LMZA2 kan compressen... maar dat lukt mij anders ook nog wel dmv. batch/powershell en "Task Scheduler"

Wederom, ben blij dat jullie allemaal veel kennis hier aan de hand van op doen, maar dit hoort een simpel iets te zijn voor de gemiddelde tweaker.

Dus.... welke tool kan ik hiervoor gebruiken?

Thanks guys

Dump python en kijk naar node.js. Met een array van sockets en .pipe of .on('data')/.write is dit super simpel te doen, zo lang de client inderdaad geen connectie 'opzet'.
Eigenlijk gewoon dit: https://gist.github.com/creationix/707146 Maar dan met een extra client en je piped de data van de client naar alles wat op jouw socket connect.

Pseudo code:

code:

var net = require('net'),
    clients = [],
    realServer = new net.Socket();
realServer.connect(1337, 'server.mijndomein.nl', function() {
    net.createServer(function(socket) {
        clients.push(socket);

        realServer.on('data', function(data) {
            clients.forEach(function(client) {
                client.write(data);
            });
        });

        socket.on('end', function() {
            clients.splice(clients.indexOf(socket), 1);
        });
    }).listen(1337);
};

Even een beetje opfrissen (code stijl) en wat foutafhandeling (+reconnect) en klaar.
Voor reconnect, LZMA en logging kun je zo kant en klare modules van NPM plukken.
https://www.npmjs.com/package/eversocket
https://www.npmjs.com/package/lzma
https://www.npmjs.com/package/basic-logger of https://nodejs.org/dist/l...osition_encoding_callback

[ Voor 26% gewijzigd door |sWORDs| op 22-02-2018 12:21 ]

[laurens0619]

Precies met @|sWORDs| dit knoop je zo met nodejs in elkaar en de “gemiddelde tweaker” draait hier zijn hand niet voor om

Of het daarna werkt hangt van de applicatielogica af maar die discussie is vaak genoeg gevoerd. Dus hup aan de slag met nodejs/wireshark, leuk tweakerproject!

[ Voor 37% gewijzigd door laurens0619 op 22-02-2018 23:00 ]

[michaelbar]

Hi allen,

Intussen hier een dev voor gevonden, thanks voor alle hulp

Fijn weekend