zelfde boodschap naar meerdere IP's

[The_Butler]

Wat ik nu neerzet is een klein onderdeel van een vrij groot probleem wat ik probeer op te lossen. het komt erop neer dat ik naar 1 tot 255 verschillende IP adressen een data pakket wil sturen, het pakket zal in alle gevallen exact hetzelfde zijn, de enige variabele is het IP adsres, is er een manier om op een netwerk een boodschap te sturen die door iedereen in een bepaalde IP range gelezen wordt? Het is erg slecht voor de performance van het netwerk als ik 255 keer hetzelfde pakketje op het netwerk moet sturen terweil alleen het IP adres anders is.

Alle IP adressen zitten in dezelfde range.

Als er iemand heel nieuwschierig is naar het complete verhaal dan ben ik wel bereid dat ff neer te schrijven, t gaat om een industrieel netwerk..

alvast bedankt voor t lezen

[Routed]

multi-cast mischien een oplossing??

http://www.cisco.com/warp/public/779/largeent/learn/technologies/multicast.html

verder ffkes googlen op multi cast en mischien vind je wat je wilt...

[/edit promotion crew wanabee mode]

Die cisco link is het eerste wat ik vond aangezien ik toch op de cisco site zat

Met google kreeg ik ook best veel hits oa wat over multicast onder linux ed.

[The_Butler]

tnx, ik kon het probleem wel omschrijven ik wist alleen de juiste term niet, vandaar dat de search op t forum ook weinig opbracht, ik stroop ff t internet af op zaken aangaande multicast, k hoop dat er een softwarematige oplossing voor is, de link naar de cisco site doet mij vermoeden dat er hardware in het spel kan zijn...

[mvdejong]

Nee, multicast is in principe een protocol-kwestie. Alleen moeten de netwerk-componenten, inclusief switches, dit ondersteunen. Het basis-idee is dat je een bericht naar een multicast-IP-adres stuurt, en dat elke geinteresseerde client zich "abonneert" op deze multicast. Het moeilijke aan multicast is om dit ook werkend te krijgen over switches en routers, omdat deze behulpzaam moeten zijn in het forwarden van de multicasts naar die netwerken waar de clienten zitten, en ook moeten meewerken als de client zijn "abonnement" opzegt.
Multicasting is met name bedacht voor zaken als audio- en video-toepassingen (je wilt de beeldjes van een video niet aan elke individueel geinteresseerd client-systeem apart versturen).

[The_Butler]

bedankt voor de reactie, hier nog wat extra info:

Modbus is een protocol waar één master aan meerdere slaves (PLC's, dat zijn industriele computers) opdrachten geeft.

Ik heb modules die Modbus naar TCP/IP vertalen en andersom

Ik heb dus een netwerk waar Modbus frames worden verstuurt in TCP/IP frames. In het netwerk staan meerdere modules die niet weten of het Modbus frame voor hun slave bedoeld is, de enige manier om er achter te komen is om het Modbus frame aan de slave te geven en die te laten bepalen of het frame genegeerd moet worden of dat er actie ondernomen moet worden.

Om goede communicatie te hebben moeten alle modules hetzelfde TCP/IP frame ontvangen, doorgeven aan de slave en dan luisteren of de slave iets terug zegt. Als ik het goed begrijp kan dit met multicasting. Heb ik hier speciale software voor nodig? speciale hardware, speciale eisen voor de modules?

Ik hou jullie op de hoogte als ik zelf iets interresants vind.

[reddog33hummer]

in princiepe kan dat met multicasting ja .....
maar dan moet wel je netwerk 1000-1000 zijn want anders heb je geen goede kwalitiet.
Het probleem met multicasting is dat het niet kent van
"wat zei je... stuur even packetje X nog een keertje"

Het is orgineel voor video en audiobroadcasting bedoelt dus dan is het niet erg als hier en daar een packetje wegvalt.

[vso]

Op vrijdag 29 maart 2002 00:44 schreef The_Butler het volgende:
Ik heb modules die Modbus naar TCP/IP vertalen en andersom

Ik heb dus een netwerk waar Modbus frames worden verstuurt in TCP/IP frames. In het netwerk staan meerdere modules die niet weten of het Modbus frame voor hun slave bedoeld is, de enige manier om er achter te komen is om het Modbus frame aan de slave te geven en die te laten bepalen of het frame genegeerd moet worden of dat er actie ondernomen moet worden.

Om goede communicatie te hebben moeten alle modules hetzelfde TCP/IP frame ontvangen, doorgeven aan de slave en dan luisteren of de slave iets terug zegt. Als ik het goed begrijp kan dit met multicasting. Heb ik hier speciale software voor nodig? speciale hardware, speciale eisen voor de modules?

als ik goed begrijp wil je aan een X aantal machines dezelfde info zenden, in DHCP zit een aantal faciliteiten.
- MAC adress based transmission (hardware adres)
- toekennen van een adress
- broadcasting via 0.0.0.0 vanaf client naar 255.255.255.255 server en visa versa

dan is afhankelijk hoeveel clients en servers je hebt,
dhcp is niet alleen dynamisch maar je kan ook dynamisch "statische" servers aanwijzen d.m.v het mac adress in de database optenemen en daaraan een IP te koppelen geeft je veel meer flexibiliteit en je kan hierdoor als je dit aan een dynam. dns nog veel meer opties mee doen

classful of classless subnets geven je nog meer flexibiliteit. in 1 v.d 2 classes kan je zelfs meer dan 255 clients in 1 netwerk bereiken.

het verschil tussen broadcasting en multicasting kan ik je hellaas niet uitleggen.

[vso]

Op vrijdag 29 maart 2002 01:38 schreef reddog33hummer het volgende:
in princiepe kan dat met multicasting ja .....
maar dan moet wel je netwerk 1000-1000 zijn want anders heb je geen goede kwalitiet.
Het probleem met multicasting is dat het niet kent van
"wat zei je... stuur even packetje X nog een keertje"

Het is orgineel voor video en audiobroadcasting bedoelt dus dan is het niet erg als hier en daar een packetje wegvalt.

dit is natuurlijk niet wensenlijk in een bedrijfsnetwerk.
UPD vs TCP prob. maar dit zou je natuurlijk ook op kunnen lossen door een recive bevestiging sturen naar de verstuurder.

tevens als je een ontvangstbevestiging terugstuurt/krijgt dan heb je als voordeel dat je ook weet dat het wel/niet present is.

[Verwijderd]

Modbus is een protocol waar één master aan meerdere slaves (PLC's, dat zijn industriele computers) opdrachten geeft.

programmable logic controllers zijn industriele comps... hmmm wel wat teveel eer voor die dingen...

[The_Butler]

oke oke, mischien is industriele computer iets teveel eer, maar om nu helemaal uit te leggen wat die dingen doen en zijn gaat een beetje ver...

dit komt uit de manual van de module:

The serial data is encapsulated and transported over Ethernet providing transparent serial communication. It is also possible to communicate one to many (master/salve) by using a broadcast network address.

(http://www.westermo.se/welcome/westermosite.htm) ED-10

k probeer nu uit te zoeken hoe ik via t broadcast adres data kan versturen, de hoeveelheid aan open browser windows en aantekeningen begint schrikbaren te worden, er is heel veel info te vinden over deze onderwerpen maar t is moeilijk om t grote geheel te overzien...

[Verwijderd]

let op een broadcast is niet hetzelfde als multicast...

broadcast >>> naar alle apparaten op 1 subnet. (dit werkt altijd niet afhankleijk van switches oid... alleen je pc's moeten het "bericht" wel goed kunnen afhandelen; oftewel er moet software voorgeschreven worden/zijn)
multicast >>> zie hierboven... volgens mij is dit ook onafhanklijk van een subnet maar dat weet ik niet zeker... (gaat dit over een router zonder bootp??)

[Verwijderd]

Kan je dat data pakketje niet gewoon broadcasten
Dus stuur het pakketje naar ip: x.x.x.255
Lijkt mij een stuk makkelijker.....

[reddog33hummer]

hij praat over 255 machines....

het kan zijn dat hij in hetzelde sigment bedoelt (dan kunnen er nooit 255 machines zijn), dan is broadcast een optie, het probleem is dat het wel bevestigd moet worden omdat anders je niet weet of het aangekoment is.

als we over meerde ranges praten...

[vso]

Op vrijdag 29 maart 2002 17:47 schreef reddog33hummer het volgende:
hij praat over 255 machines....

het kan zijn dat hij in hetzelde sigment bedoelt (dan kunnen er nooit 255 machines zijn), dan is broadcast een optie, het probleem is dat het wel bevestigd moet worden omdat anders je niet weet of het aangekoment is.

als we over meerde ranges praten...

segment ipv sigment

erhm in een classfull heb je het wel over meerdere ip's echter classless niet ..

* vso pakt zijn subnet-calculator

stel je hebt 62 netwerken ... met elk 1022 clients
(beetje vergezocht I know)
dan zou het als volgt zijn:

je subnet Host Range:
128.168.4.1 - 128.168.7.25
128.168.8.1 - 128.168.11.25
128.168.12.1 - 128.168.15.25
en etc

je subnet zou zijn
255.255.252.0

wil je broadcasten naar 1 subnet zeg
bv: 128.0.1 - 128.168.3.254 (als ip range)
dan zou de het broadcast adres zijn: 128.168.3.255

wil je naar alle subnetten broadcasten dan zou je als broadcast nemen voor de TOTALE range: 128.168.255.255

classless werkt namelijk op het principe van bits ipv 0 of 255
8 bits = 1 byte
11111111 (bits/binair stelsel) = ff (HEX/16tallig stelsel)

het ideale van classless ten opzichte van classfull = dat je bv per x aantal hosts en x aantal netwerken in 1 groot netwerk kan laten samen werken en dat je hierdoor broadcasts effectief in de juiste doelgroep doet. MAAR je behoudt toch de optie om ze allemaal te bereiken ..

in een classfull netwerk heb je per a.b.c.d range nog steeds 1 netwerk die dus overladen wordt met broadcasts in 1 netwerk thuishoren dus meer achtergrond verkeer dus meer problemen
denk aan meer verkeer dan jij wil weten bij een 10.x.x.x
netwerk die naar elk mogelijke pc die er in het netwerk hangt ff zit te broadcasten.. dan is je netwerk kwaliteit in 1 keer BUT

[The_Butler]

oke, k heb heel veel nuttige suggesties gezien hier, alvast bedankt. Dinsdag ga ik wat testen en probeer ik via een broadcast iedereen op het netwerk van info te voorzien. Alleen vraag ik me af wat er gebeurt als er communicatie fouten ontstaan... of als er teveel data verkeer gegenereerd wordt..

maat daar kan ik nu weinig zinnigs over zeggen.. nogmaals heel erg bedankt en ik hou jullie op de hoogte!

[vso]

Op zondag 31 maart 2002 01:43 schreef The_Butler het volgende:
oke, k heb heel veel nuttige suggesties gezien hier, alvast bedankt. Dinsdag ga ik wat testen en probeer ik via een broadcast iedereen op het netwerk van info te voorzien. Alleen vraag ik me af wat er gebeurt als er communicatie fouten ontstaan... of als er teveel data verkeer gegenereerd wordt..

maat daar kan ik nu weinig zinnigs over zeggen.. nogmaals heel erg bedankt en ik hou jullie op de hoogte!

teveel dataverkeer zou je dus kunne scheiden d.m.v. classless networking .

communicatie fouten tja das weer een ander verhaal

[The_Butler]

een ander verhaal, k weet t. Als je 1 broadcast frame verstuurt met een fout erin dan kan je dus van ieder IP een foutbericht verwachten, daardoor krijg je waarschijnlijk veel collisions en andere storingen... kunnen dit soort voorvallen je hele netwerk op ze'n gat leggen? zijn er maatregelen te nemen, of zijn er vuistregels zoals niet meer dan een x aantal IP's tegelijk broadcasten (als je met subnetten werkt)

k moet er niet aan denken dat 254 IP's tegelijk gaan reageren op een netwerk, of valt dat eigenlijk wel mee?
iemand ervaringen?

Ook leuk detail is dat ik test met 3 modules, hoe kan ik siumuleren dat ik met 254 modules werk? Mijn netwerkje kan perfect werken in mijn testopstelling maar constant op ze'n gat liggen als t in t groot in bedrijf wordt gesteld...

iemand hiermee ervaringen?

[reddog33hummer]

zon testprobleem heb ik ook gehad.

we hadden een systeem waar ongeveer 60000 users aan hingen.... we hadden niet even 60000 users om mee te kunnen testen.

Je kan dan 2 dingen doen, of je gaat het simuleren met programma's (60000 threaths openen en gaan met die banaan) of je pakt een wiskundige aanpak.

omdat de wiskundige aanpak nogal ingewikkeld is (statistiek)
hadden wij er voor gekozen om dmv. 5 systemen en een programma zo'n 60000 users te emuleren.

[reddog33hummer]

het grote probleem aleen met ethernet is dat als het drukker wordt dat er meer packeteen verloren gaan.

dus als je naar 255 machines iets mis gaat (of de bevestiging) komen op hetzelfde moment 255 machines terug => packetloss ze wachten allemaal en proberen het nog een keer (niet allemaal 100% op hetzelfde moment maar toch genoeg voor weer een X aantal packetloss).

het moment dat het andwoord terug komt "hangt" je netwerk.
dus zoizo moet je het terugsturen wel even "dirigeren" anders zit de boel vast.

[Aetje]

Hmz... Dat hangen doet me denken aan het HSL netwerk (hogeschool zuyd - heerlen).

[The_Butler]

Quote van reddog33hummer - maandag 01 april 2002 21:38

het moment dat het andwoord terug komt "hangt" je netwerk.
dus zoizo moet je het terugsturen wel even "dirigeren" anders zit de boel vast.


Kun je iets specefieker zijn over dat "dirigeren"?
Ik begrijp niet helemaal wat je hiermee bedoelt...

[vso]

denk dat tie onder derigeren verstaat dat je een soort "route" c.q "time" probleem krijgt. stel je voor 255 man staat in een zaal jij als 1 van die 255 roept is iedereen der ? kan jij dan van iedereen die ja zegt dan de naam etc in 1 keer opschrijven en present noteren ? .. nee dus je moet zorgen dat ze dat in groepjes doen.

emulatie en wiskundig zou ik beide pakken om het te testen of het wel of niet werkt . praktijk is altijd anders dan de theorie. En met de data van beide kan je beter conclusies trekken dan met 1 van de 2.

btw een pakketje heeft een TTL (Time To Live) en een Hop count:
de TTL geeft aan als ik bvtussen 0 en 1 seconde nog niet bij de bestemming ben .. verdwijn ik in de bithemel
Zelfde is voor Hops een hop is een sprong van router/switch/ cq node dus .. dat een pakket nodig heeft om de bestemming te bereiken indien deze BV: niet binnen 125 hops bij zijn bestemming is --> bithemel.

de oplossing voor dataverlies zou zijn de ttl te verhogen.

tip lees eens wat meer over de BASICS van IP en NETWERKEN .. dit is over het algemeen common nowledge

wat je ook kan doen is dmv geloof ik mijn eerder voorbeeld DHCP voorbeeld alles een dhcp lease geven van x tijd
uit de lease haal je de "bestaande clients" en die ga je vervolgens met je prog af om te kijken of deze de reactie geeft die je wenst te ontvangen.

dhcp kan er voor zorgen dat weet dat m.b.v een vooringestelde interval of de apparatuur zoiezo nog actief is.

wat je inderdaad wil vermijden in je netwerk is veel verkeer. hoe meer verkeer hoemeer collisions maar ipv hubs switches te gebruiken verklein je weer de kans met collisions.

ik zou hiervoor een wiskundige aanpak gebruiken om uitterekenen hoeveel je verkeer gaat genereren en of je apparatuur hier mee overweg kan.

[The_Butler]

Was ik weder, k heb vandaag ff wat info vergaard en een aantal van de in deze thread genoemde suggesties opgevolgd. Om het geheel iets duidelijker te maken heb ik ook een foto van het geheel, dan hebben jullie een iets beter idee waarover ik het heb.



dat witte ding dat RUN zegt is mijn PLC (Hima A1 Digital) en die bruine Module is mijn Westermo ED-10

Tussen de ED-10 en de PLC loopt een RS485 kabel (RxTxA & RxTxB & GRND). Van de ED-10 gaat er een netwerkkabel (blauw) naar mijn hub, links van de opstelling staat nog een PLC en ook nog een ED-10 module.

De Modules kunnen GEEN IP adres verkrijgen via DHCP, de instellingen die ik mag maken zijn:





kan het volgende vertellen over mijn netwerkje...

- Ik heb geen mogelijkheid om DHCP te gebruiken voor de Modules
-Mijn programma die seriele data omzet naar TCP/IP staat niet toe dat ik data naar het broadcast adres stuur.
(http://mat018102.student.utwente.nl/cupido/serial-ip)
-Een ping van het broadcast adres resulteert in een timeout.

Ik begin nu te tweifelen of wat ik wil eigenlijk wel haalbaar is, wat ik wil, kort samengevat:

TCP/IP pakketten van het prgramma Serial/IP moeten naar iedere ED-10 module verstuurd worden. Foutcorrectie gebeurt voor een groot gedeelte al door het Modbus protcol, TCP/IP fouten kunnen genegeerd worden.
Iedere modulle moet de mogelijkheid hebben om met het hele netwerk te communiceren (PLC 1 praat bijv. met PLC

t is weer een heel verhaal geworden, sorry als de foto's een iets te groot formaat zijn. bedankt voor t lezen, een closeup van de ED-10 is te vinden op http://mat018102.student.utwente.nl/cupido/ed10

[Aetje]

Vraag me af waarom je voor TCP gekozen hebt. Dit was eenvoudiger te doen met een eigen protocol... Maar als je zonder router en switch werkt, zit dat met de communicatie wel goed. Elke NIC krijgt immers IEDER frame. Wellicht kun je hier een truc toepassen die niet hoort, maar wel kan:
Zend gewoon een niet-IP compatibel frame over 't netwerk als je een broadcast wil doen. Moet je zelf even iets in elkaar programmeren, hoe het antwoord moet zijn. Iets in de trend van:

PLC1 : Bericht voor PLC5. PLC5, stuur me je IP!
(dit bericht is niet TCP compatibel, gaat over het hele netwerk heen.)
PLC5 : *pingt PLC1*
PLC1 : *Stuurt info naar PLC5*

Rest van 't netwerk is onbelast.

[The_Butler]

tja, de keus om met een Ethernet netwerk te werken is puur voor research. Het komt nogal is voor dat een bedrijf al wel een ethernet netwerk heeft maar geen RS485 netwerk, dan werkt het dus super kostenbesparend als onze PLC's (die overigens een Bus-nummer inplaats van een IP adres hebben) in kunnen tappen op het bestaande ethernet netwerk. Ook wordt het gemakkelijker om data te routeren, met swiches te werken en de communicatie met laptops, internet servers, het kantoornetwerk van een bedrijf etc tot stand te brengen. Kortom, ik doe onderzoek of dit mogelijk is, en ik kom van huisuit uit de Industriele automatisering, k weet wel een en ander van TCP-IP, DHCP, subnetten en het programeren van een (Cisco) router, Maar ik heb simpelweg de kennis niet in huis aangaande het broadcasten / multicasten over een netwerk. Ik begin nu zelfs te tweifelen of het wel echt haalbaar is wat ik wil...

[vso]

Op woensdag 03 april 2002 00:00 schreef The_Butler het volgende:
tja, de keus om met een Ethernet netwerk te werken is puur voor research. Het komt nogal is voor dat een bedrijf al wel een ethernet netwerk heeft maar geen RS485 netwerk, dan werkt het dus super kostenbesparend als onze PLC's (die overigens een Bus-nummer inplaats van een IP adres hebben) in kunnen tappen op het bestaande ethernet netwerk. Ook wordt het gemakkelijker om data te routeren, met swiches te werken en de communicatie met laptops, internet servers, het kantoornetwerk van een bedrijf etc tot stand te brengen. Kortom, ik doe onderzoek of dit mogelijk is, en ik kom van huisuit uit de Industriele automatisering, k weet wel een en ander van TCP-IP, DHCP, subnetten en het programeren van een (Cisco) router, Maar ik heb simpelweg de kennis niet in huis aangaande het broadcasten / multicasten over een netwerk. Ik begin nu zelfs te tweifelen of het wel echt haalbaar is wat ik wil...

tja denk wel dat het haalbaar is, dan wel niet met een "workaround"

misschien dat je eens in de *nix hoek moet gaan kijken of ze daar werken met dezelfde spul als je het nu ff in het internet zoekmachinetje van je ramt en zoekt op "plc IP + linux" of iets in die geest ? dan hebbie kans dat er mensen zijn geweest die er ooit werk van hebben gemaakt ..
kan niet is onmogelijk in de computer wereld ..
aleen is het kosten+baten plaatje dan wel nog in orde ?

kijk als je elke plc kan her progammeren dmv een embedded linux stukje .. ertussen, erbij ofzo te doen dan is het misschien nog wel te doen maaruh waar ligt je grens in dit geval ?

btw voordeel van (embedded) *nix is dat het zeer klein kan wezen.

[TrailBlazer]

Op donderdag 28 maart 2002 23:15 schreef mvdejong het volgende:
Nee, multicast is in principe een protocol-kwestie. Alleen moeten de netwerk-componenten, inclusief switches,

Dot vind ik gek het is toch zo en zo een laag 2 broaadcast. Het is natuurlijk mogelijk omhet mac adres van al je machines zo aan te passen dat je daar weer een mulicast op kan doen. Dat is echter ongebruikelijker dan een aantal adressen in dezelfde ip reeks te plaatsen