Why did they implement a hard realtime application using TCP?
This what UDP is for.
If you use TCP you will get a long pause where the "voice data" queues up for very long everytime you have to take a retransmission.
With hard realtime applications such as voice it is much better to never have these delays and instead just accept that the data is lost hence udp.
(for quality voice if the packets are delayed more than 100ms end to end it is pointless to do retransmissions anyway such as tcp retransmissions.
for cheap low end internet voice i guess you can accept up to 250ms delays)
On 9/7/06, Still Life <still.life@xxxxxxxx
> wrote:Hi,
my name is Fabio and I'm from Genova, Italy.
I'm developing a plugin dissector for a protocol used by
a telephony over IP application on top of TCP protocol.
Packets have this format:
|<-----------------myMsg------------------->|
|---------+--------+----+------------+--------+--||---+
|tcpHeader|55555555|0000|mesageLenght|messgeId|details|
|---------+--------+----+------------+--------+--||---+
I wrote with good results a dissector that dissect any signle
packet containing one ore more different type of message (messageID)
but when packets are fragmented I don't know what to do.
Example of fragmented Packets:
firstpacket:
|----------+--------+----+------------+--------+-----------+
|tcp header|55555555|0000|mesageLenght|messgeId|veryLong...|
|----------+--------+----+------------+--------+-----------+
^(offsetLastMsg) ^Fragment!
secondpacket:
|----------+----------+
|tcp header|...details|
|----------+----------+
firstpacket:
|----------+--------+--------+-||-+----------+--------+----+
|tcp header|myMsg(1)|myMsg(2)|... |myMsg(N-K)|55555555|0...|
|----------+--------+--------+-||-+----------+--------+----+
^offsetLastMsg^Fragment!
secondpacket:
|----------+------------------------+-||-+--------+
|tcp header|...myMsg(N-K+1)(partial)|... |myMsg(N)|
|----------+------------------------+-||-+--------+
The first tcp header is already dissected and the tvb passed
to my dissector start from the first 55555555.
With the use of tvb->length and the info present in each
if myMsg (mesageLenght) I'm able to determine if a packet
is fragmented.
In the two fragmented case, in the function
dissect_protocol(tvp,pinfo,tree) I would
like to save the current tvb fragmented portion:
if(fragmented reveal condition...)
{
fragmented_flag=1;
previous_tvb = tvb_new_subset(tvb , offsetLastMsg, -1, -1);
}
and when the second part arrive I would like to make a
complete_tvb that contain the new data, something like:
if(fragment_flag)
{
complete_tvb = tvb_merge(previous_tvb, tvb);
}
and dissect complete_tvb instead of this one.
I read the developer manual, README.developer, other dissectors
code and search in the old message and on google but I
can't figure how to do that.
I read the "How to reassemble split packets" in the developer
manual and try to code something similar...but I was not able
to make it work.
I never do a similar work before, please, can someone help me?
Thanks in advance,
Fabio
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Refill srl il paradiso della tua stampante - cartucce e toner compatibili, inchiostri e accessori per la ricarica, carta speciale. Tutto a prezzi scontatissimi!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5187&d=6-9
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
