Hi all,
I am trying to build a wireless lan with 3 qnx6.3.2 machines. now i wanna use udp sockets to realize peer-to-peer wlan. So i need to embed both client and server implementation in two threads in each machine. I have also other threads in each machine. Is it suitable in this case? Besides, I will arrange them to run in a pre-defined order.
Specifically, after all the initialization, like socket creating and binding, when it is server’s thread turn to run, it just accepts and does some processing. then comes the client’s turn to send pkts. All the threads run once every 20ms. So in each 20ms cycle, one machine may receive more than 1 pkts from others. How should i buffer the udp packet then?
Another issue is the medium access. Considering the real time requirements, i tried to deploy wireless token ring protocol in each one, so that at any instance only one machines has the chance to talk.
Look forward to ur comments and suggestions. thx
Real-time requirement + wireless don’t really work. Wireless is an extremely unstable medium. Doing a logical token ring config is useless for wireless. When wireless is used, there is a lot more going in the air then the data you are trying to send. Plus if you use any sort of standard protocol like TCP/QNET you will end up with extra traffic that you can’t really control and that will break the token ring concept.
Why use UDP instead of TCP or QNET?
I’m not sure what you mean by “how should I buffer the udp packet”. The stack has some internal buffer ( you can control its size to some extent) so it will take care of buffering. However if the buffers are full the packets will be lost. When I do UDP I like to use a thread that will pull the data as fast as possible and I’ll do my own buffering if need be.
But my application must be carried out in the wireless medium. so in my opinion, wireless token ring should be better than nothing. of course, i may use tcp and qnet. I just want to implement udp first and then incorporate them all in the communication module. but in my current application where small packet and efficiency are required, i think udp would be the best solution. what’s ur opinion abt the wireless token in the above paper?
“When I do UDP I like to use a thread that will pull the data as fast as possible and I’ll do my own buffering if need be.” Could u please give me a detailed description for ur method? thank u.
Didn’t it read it all cause after all I’m doing this for free, but the first thing that pops up is the paper says it’s a MAC protocol not an IP protocol. That comes down to what I was saying in my first response. Unless you have complete control, implementing a token right may be futile.
[quote=“Ericxx”“When I do UDP I like to use a thread that will pull the data as fast as possible and I’ll do my own buffering if need be.” Could u please give me a detailed description for ur method? thank u.[/quote]
In a nut shell thread 1 does the reading
while(1)
{
char buffer[x];
size = recv(buffer);
queue_size++;
memcpy( queue[front++], buffer, size )
// MsgSendPulse or your other favorite method of notification
}
The other thread waits for data to go in buffer
while(1)
{
pid = MsgReceive();
if ( pid == data receive )
{
if ( queue_size != 0)
{
process ( queue[tail++] )
–queue_size
}
}
else if ( pid … )
{
}
This is so common that I ended up creating a C++ template for handling the circular queue. Could have use STL++ but mine does all the allocation before hand and doesn’t required any synchronisation method ( mutex or other) hence it’s fast and lightweight.
I forgot to mentionned, because the protocol is meant to operate at the MAC layer, it assumes that any error is handled at the protocol level. That means if you use UDP you may have to implement your own correction for missing, duplicate, out of order packets etc.
I read a bit of the paper. It's not Token Ring at all, if you happen to know where the name comes from. Token Ring is a token passing protocol that IBM used early on with PC's. The Ring part comes from the fact that the nodes had to be wired in a ring. A better name would be Token Passing. The author does a number of things to make himself look naive. To start with he uses real time in a cavalier way, without addressing the issue of public air. Basically he is addressing the collision vs token passing design we dealt with year ago. In a network with activity anywhere near capacity, collision based system degrade very badly, while token passing systems degrade in an efficient and fair manner. To transfer this idea to wireless, you have assume quiet airspace. This may not be unrealistic is some applications, but unlike wires, wireless packets don't have to collide to not go through. If for example, the signal is weak, there may just be a probability of it going through.
I would create a small setup with some test program to try tcp / qnet and see if those meet your requirement. If they don’t then you might have to use UDP which gives you better control how you handle errors/timeout, at the price of complexity.
Thank you, mario and maschoen.
My application scenario is like this: 3 outdoor vehicles with wifi work coordinately in an open field. i just wanna a simple token to coordinate the communication among the 3 vehicles. At any time only one has the token and just send out its msg to the other two. after the time of holding token runs out, it passes the token to the next vehicle. and this procedure keeps running on 3 vehicles.
So what i need to do is first make the 802.11b network card work in the DCF mode, then append the token msg to the normal packets to realize tokening. Then the errors or timeout can still be handled at the ip layer. Waiting for your responses.
To mario, could you please also post your testing code? so that i may also do some testing in the further based on your version. i am a newbie in programming. thanks again.
I don’t see any reason to use token passing. Just send a serialized packet and wait for an ACK. If the wait times out, resend until it does. When receiving, keep track of the serial number. If a packet comes in with a duplicate, the ACK didn’t go through, so discard the packet and resend. Unless you are trying to use most of the available bandwidth on a channel, this should work fine.
thx. but what if i want to know exactly who should be the sender next time? If the number of taking nodes become to about 10, then i should have a clear mind that after node 5’s transmit, node 6 should become the next sender. If we use the traditional mac protocol, then at a given time, we could not be sure who will send next. Besides, the time delay from src to dest would be non-deterministic. Am i right? thx again!
thanks.
To mario, we just send small packets with less than 1000Bytes per packet. and the transmission rate would come close to 11Mbps within short communication range. and the 3 vehicles are all equipped with QNX6.3.2.
To kwschumm, you are right, we have gps installed on each vehicle. but i am wondering that the accumulated clock shift among the vehicles would lead to the asynchronization. i will check with the gps specs.
I’m not talking about transmission rate of the wireless but the amount of data that needs to be transfered. What I’m trying to get at is if your wireless is 11Mbits and you need to transfer a total of 1mbits per seconds (for all three system combined ) then there is no need to worry about “collision” at all. Same as you would with ethernet.
GPS clock doesn’t shift/drift, it’s stable, very stable
Roughly, 1Mbit per second for each vehicle. So under what situations will the wireless transmission behave as the ethernet? look forward to ur explanation. thx.
Wireless behaves like Ethernet from an application point of view. The wireless network card handles all the specific of the wireless protocol (it’s far more complicated then ethernet). Think of it as a 10mbits Ethernet network connected via a hub (not a switch )
The token passing you mentioned make sense to me as a sort of Qos to ensure your application get the bandwidth in needs when it needs when resources are scares. With so much room to spare, I woudn’t worry about it, doesn’t seems worth it to me.
However you must be prepare to handle cases where the speed of the network drops or communication drops for x amount of time. For example lighting storm, or if the vehicles are equipped with micro wave oven
thx, mario. i am afraid in the wireless communication scenario, even if there is spare room for the data transmission, but as long as one vehicle is sending packets, then all the other two have to wait until the medium is available. but considering the light speed of the wave, the transmission duration is so short that the chance is quite small that all the nodes begin to send pkts at the same time, i.e. collision is rare.
yes, i will explicitly add ack and timeout mechanism based on udp. btw, we do have other devices operating at the 2.4G. Basically, i am trying to avoid the interferences by making that the devices work on separate channels of 802.11, i.e. 1, 6, 11. still like to have your advice. thx.
Like ethernet, a wireless device listens to the media, and when it thinks all is clear, it sends. This does not remove the possibility of a collision. When using a reasonable percentage of the bandwidth, I think 1/3 is reasonable, then collisions are rare enough that you don’t have to worry about token passing. It’s only when you want to use a high percentage of the bandwidth, that your throughput will drop due to collisions.
The other two always have to wait until the medium is available. If you implement token passing, then they have to wait until they get the token. In either scenario there is bandwidth loss. In one case it is from collisions. In the other from token delay and token loss. If your use of the bandwidth does not cause severe loss from collisions, then it is a much simpler way to go.
What you are saying is that if I have 2 computers with a wireless card connect to internet via wireless route and one of them is doing a ftp transfer that the other computer won’t be able to transfer anything. Nah that’s not how that works. You can have 2 computers transfering max speed at the same time and it will work just fine, slower but it the bandwidth will be shared.
I’m not talking at the protocol level, I’m talking about how will the system behave when it lost communication for say .5 seconds. Will it crash, fault, ignore the error and retry, display error message, log the event, etc.
