I have been using the EWEB for several years because it was the only way for a Rockwell PLC to send multicasts without using Ethernet/IP (which consumed a connection for every LISTENER, destroying any scalability that would otherwise be achieved using pure multicast based data acquisition).
If you have no experience with socket programming, doing it in the EWEB will be a nightmare. If you are a socket programming expert, it will be EVEN WORSE, because you know how to do everything in a C++ type language but you still can't do anything in the EWEB without looking up what class, instance, attribute, request structure and response structure required for each single step in the socket creation process. After the socket is created you have to move the instance in to every other MSG that is involved in the socket setup. No step can proceed until the previous step completes, and all MSG instructions complete asynchronous to the program scan. If there is a problem, the socket(s) must be deleted before trying the entire sequence again. Network fault tolerance and recovery is extremely painful to implement.
You can only have 20 sockets total. Single socket re-use is not possible if you are sending data in groups of simultaneous messages (as Rockwell recommends), so now you have to write code that packages your data into groups of MSG instructions that execute simultaneously.
You are also limited to a payload of 480 bytes. I think they are now coming out with a new module that can handle an MTU of ~1500.
I have done things as complex as implementing dual EWEB failover (it even detects when the edge switch it's plugged into becomes isolated from the core network) and I can easily say that i would rather die than ever write another communication routine in RSLogix.
(Before you ask "Why didn't you use the RM module for redundancy??" i will tell you that i have had experience with this as well, and using that module in your rack will dramatically increase your PLC program scan time. in our case, it's so bad we cannot achieve a 100ms data update rate, because the PLC's synchronize after every program scan, pushing it to somewhere between 500ms - 1200ms. After following Rockwell's recommendations for optimizing data, we got it down to 460ms, which was still unacceptable.)
