I am currently putting together an EpiServer 6 Enteprise solution consisting of 2 "frontend" web serveres and a "backend" publishing server. I am having some troubles getting the uod broadcast messages from the publishing server to reach the frontend servers for cache invalidation. First I thought it had to do with the udp messages was being stopped in the firewall between the 2 netvork segments, but after some closer inspections it seems that the upd messages were not leaving the pubishing server at all. The server is configured with 2 NIC's. 1 for normal trafic and one for taking backups. Using Wireshark to sniff the network trafic, I was unable to see any udp broadcasts on the regular networkcard, but I could see it on the backup nic.
This is as you might understand not my best skill, so hopefully this is not a stupid question... Could it be a problem with this udp broadcasting on servers with mulitple NIC's ? Have anyone else seen something similar, and what did you do to fix it? I am also checking if there is some other hardware boxes (switches etc)that blocks the udp traffic, but I figured I should ask the forum as well :-)
You should perhaps try using TCP for broadcasts we've had reliability issues using UDP and have given it up entirely. And we've been running the same 2 nic setup as you are describing.
I have had problems with that the switch stoped multicast, and therefor stoped the udp trafic
Routers don´t support UDP multicast, but switches should let it pass. We are experiencing the same problem.
Have anyone successfully used the soaptcp approach. We cant get it to work with an two site setup using Enterprise.
We are stuck getting socket problems as an cause of both sites trying to start the same listner on same port. When we enabled net-tcpsharing we got another problem regarding not unique URI.
We are using CMS6 (not the R2 beta).
Daniel: Perhaps you've forgotten to use the steid as part of the name in the endpoints which you've configured?
Shamrez!Thanks! That was the problem, we missed that part totally. Where did you find that info? It seems that the documentation is lacking a bit on that area.
If I even suspect there is a firewall, router or advanced switch somewhere in the mix, I always go for the tcp solution. It works, and is pretty much reliable as long as the network is up.
Beware of a problem with using tcp if the front end servers do not do cache invalidation themselves (which is pretty much the norm in secured setups with read-only front-end servers.) CMS 6 do not listen (service section) on tcp if there is no registered clients. Set up udp clients on front end servers to get around this, while listening on tcp. Should be fixed in R2.