Is it possible to guarantee order of broadcast packets sent from different hosts connected via a switch?

Hi, I've a problem that I'm hoping to solve at the transport layer - but I doubt its possible.

If two machines (connected ethernet via a switch) send the same broadcast packet to their subnet at the same time, will the switch transmit the packets out such that both machines will receive the packets in the same order (whichever order that maybe)?

How I see it is that box1 sends broadcast mesg1 to the subnet when box2 sends broadcast mesg2 to the same subnet.  The switch receives both mesages and queues both to be sent out (mesg1 or mesg2 may be queued first).  
The two messages are then sent in the same order to box1 and box2.

Are there switches on the market that ensure this bevhaviour - or do other factors come into play that make this sort of guarantee impossible?



wernerf2Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Brain2000Commented:
It all depends on the switch.  Most have a hardware queue that holds packets until the switch processes them.  But the switch would have to process them in the exact order they arrive, which depends on the switch design.  Since the switch depends upon each port to tell the switch, in some fashion, when there is data, and it is up to the switch to either handle the ports in a round robin fashion, or sit idle waiting for an interrupt.

Plus there are other factors.  The ethernet line distance could make a difference of a few microseconds.  A bad network cable that causes random CRC errors.

If you only need something as reliable as two systems broadcasting about a millisecond apart, then the switch will almost certainly broadcast them back out in the same order it received them.  If they are both received within a few CPU cycles of each other, you will probably get varied results.
Don JohnstonInstructorCommented:
>Are there switches on the market that ensure this  bevhaviour - or do other factors come into play that make this
>sort of  guarantee impossible?

No. Layer 2 switches are FIFO devices. You can implement QOS and prioritize the traffic, but that won't necessarily guarantee the ordering.
Brain2000Commented:
I just had a thought.  It sounds like you are writing an application where two systems can trigger a broadcast packet, and the one that generates it first needs to win.  If that's the case, you could do this:

As long as both systems that can generate the broadcast are synchronized to the same SNTP server, their timestamps should be just about identical.  When one needs to send a broadcast, have it generate a local timestamp and include it in the broadcast.  Then, if it receives a broadcast, it will compare the timestamp in the broadcast with the timestamp of it's own last broadcast time.  If the broadcast received has an newer timestamp, then that node did not trigger first.

You'll want to use a high precision timestamp which includes milliseconds and/or microseconds.  Here's a blog that talks about that.
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/cf054024-f3d2-4958-bf1c-a84654663529
CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

wernerf2Author Commented:
You're right in what I'm trying to do and I considered using time tokens but 'should be just about identical' is a problem and being dependent on clocks is a bit of a risk I want to avoid.  I was interested in solving the problem using the switch as it is already an entity central to the system and has visibility to what all hosts are sending/receiving.  Nowadays they seem to be capable of fairly fancy things with load balancing HTTP requests and sticky sessions etc.

I've thought about it a bit more too, and I think the minimum is that the switch needs to drop duplicate broadcasts UDP packets that share the same ID (stored in a portion of the packet).  So if the hosts send a packet with the same ID the switch guarantees only one is broadcast back to the servers.

I was hoping that my problem was common to most distributed systems or to systems that require active/active failover and that there would have been 'standard' protocols supported by switches which do what I described.
Brain2000Commented:
There are various methods to "fencing".  I've heard of some where both computers log into an ADP powerswitch and attempt to shut each other down.  The computer still standing is the winner.  Clearly a violent and bloody way to determine :)

I would set this up by having both servers attempt to create a file in a shared location with exclusive access.  The server that obtains the exclusive rights wins.  The server that does not, ... well, should just shut itself off.  hehe.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
This question has been classified as abandoned and is being closed as part of the Cleanup Program.  See my comment at the end of the question for more details.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking Protocols

From novice to tech pro — start learning today.