You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Newcomb, Michael-P57487" <Mi...@gdc4s.com> on 2006/09/01 16:15:13 UTC

large messages over datagram socket

Can you give me some clues as to how to implement this? I realize that
portions of messages could get lost, so, how would you recommend
implementing a 'best effort' type of service where large messages are
split and sent, then reassembled if all of them make it, and dropped
after some time if all of them don't...

Would this be a candidate for an IoFilter?

Also, Niklas mentioned MINA 0.9, is that a release somewhere or is that
what is in HEAD?

Thanks,
Michael

Re: large messages over datagram socket

Posted by Trustin Lee <tr...@gmail.com>.
Benoit and Mike,

Thank you for the wonderful answer for UDP.  This should be listed in our
FAQ. :)

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

RE: large messages over datagram socket

Posted by Benoit Hudzia <be...@gmail.com>.
 
The only thing you can know is the maximum size of the datagram packet that
your network interface support. The MTU (Maximum Transmission Unit), the
largest physical packet size, measured in bytes, that a network can
transmit. Any messages larger than the MTU are divided into smaller packets
before being sent (you can normally tweak that value manually).
If you need to transmit large packet over a private network (controlled
environment) try enabling jumbo frame support at the network interface level
of every devices on the network. But in general case jumbo frame and general
equipment (switch etc..)  do not mix well. 
 
The problem is as soon as your packet go through another network device with
a smaller MTU it will be fragmented in smaller packet and like it often
happen for udp over the internet it will  just simply be discarded. 
 
Benoit Hudzia
Parallel Computing Research Group
School of Computer Science & Informatics
University College Dublin
Ireland
 
Tel: +353 1 716 2403
Fax: +353 1 269 7262
E-mail: benoit [dot] hudzia [at] ucd [dot] ie
Web: <http://benoit.hudzia.googlepages.com/>  Personnal Web Page,
<http://voidreflections.blogspot.com> Blog
 
 
-----Original Message-----
From: Newcomb, Michael-P57487 [mailto:Michael.Newcomb@gdc4s.com] 
Sent: 01 September 2006 15:48
To: mina-dev@directory.apache.org
Subject: RE: large messages over datagram socket
 
I just want to do packet spanning, I don't need the guaranteed part of
TCP.
 
Also, how would I tell what the maximum size is for transmitting over a
DatagramConnector?
 
Thanks,
Michael
 
-----Original Message-----
From: Mike Grundvig [mailto:mike@electrotank.com] 
Sent: Friday, September 01, 2006 10:28 AM
To: mina-dev@directory.apache.org
Subject: Re: large messages over datagram socket
 
As soon as you start implementing guaranteed delivery and packet
spanning with UDP, you might want to take a serious look at TCP again.
It's a great deal of work to implement and if a re-delivery is required,
it will often be slower then TCP. Basically, the advantages of UDP are
lost quickly once the packets get loaded down with extras needed for
custom protocols. This is why most UDP systems are based on a
fire-and-forget mentality (like video streaming or FPS games).
 
If you have to use UDP for some other reason, completely ignore me :). 
Sadly, I'm still getting my head around MINA and so I don't have any
specific implementation advice. Good luck!
 
Michael Grundvig
Electrotank, Inc
http://www.electrotank.com
 
 
----- Original Message -----
From: "Newcomb, Michael-P57487" <Mi...@gdc4s.com>
To: <mi...@directory.apache.org>
Sent: Friday, September 01, 2006 9:15 AM
Subject: large messages over datagram socket
 
 
Can you give me some clues as to how to implement this? I realize that
portions of messages could get lost, so, how would you recommend
implementing a 'best effort' type of service where large messages are
split and sent, then reassembled if all of them make it, and dropped
after some time if all of them don't...
 
Would this be a candidate for an IoFilter?
 
Also, Niklas mentioned MINA 0.9, is that a release somewhere or is that
what is in HEAD?
 
Thanks,
Michael
 

RE: large messages over datagram socket

Posted by "Newcomb, Michael-P57487" <Mi...@gdc4s.com>.
I just want to do packet spanning, I don't need the guaranteed part of
TCP.

Also, how would I tell what the maximum size is for transmitting over a
DatagramConnector?

Thanks,
Michael

-----Original Message-----
From: Mike Grundvig [mailto:mike@electrotank.com] 
Sent: Friday, September 01, 2006 10:28 AM
To: mina-dev@directory.apache.org
Subject: Re: large messages over datagram socket

As soon as you start implementing guaranteed delivery and packet
spanning with UDP, you might want to take a serious look at TCP again.
It's a great deal of work to implement and if a re-delivery is required,
it will often be slower then TCP. Basically, the advantages of UDP are
lost quickly once the packets get loaded down with extras needed for
custom protocols. This is why most UDP systems are based on a
fire-and-forget mentality (like video streaming or FPS games).

If you have to use UDP for some other reason, completely ignore me :). 
Sadly, I'm still getting my head around MINA and so I don't have any
specific implementation advice. Good luck!

Michael Grundvig
Electrotank, Inc
http://www.electrotank.com


----- Original Message -----
From: "Newcomb, Michael-P57487" <Mi...@gdc4s.com>
To: <mi...@directory.apache.org>
Sent: Friday, September 01, 2006 9:15 AM
Subject: large messages over datagram socket


Can you give me some clues as to how to implement this? I realize that
portions of messages could get lost, so, how would you recommend
implementing a 'best effort' type of service where large messages are
split and sent, then reassembled if all of them make it, and dropped
after some time if all of them don't...

Would this be a candidate for an IoFilter?

Also, Niklas mentioned MINA 0.9, is that a release somewhere or is that
what is in HEAD?

Thanks,
Michael



RE: large messages over datagram socket

Posted by Benoit Hudzia <be...@gmail.com>.
One good reason to use UDP is doing hole punching through firewall.
It enables two peers that are both behind firewall to be reachable and
communicate with each other without the hassle of using a third party to
initiate the communication. 
 
One way of implementing a way to send large message over datagram protocol
is to implement the sliding window algorithm ( used in tcp) . Yes its almost
like having tcp and as Mike Grundvig said: if you don't need special feature
like hole punching just forget about datagram and go for connection oriented
protocol like tcp.
 
 
Benoit Hudzia
Parallel Computing Research Group
School of Computer Science & Informatics
University College Dublin
Ireland
 
Tel: +353 1 716 2403
Fax: +353 1 269 7262
E-mail: benoit [dot] hudzia [at] ucd [dot] ie
Web: <http://benoit.hudzia.googlepages.com/>  Personnal Web Page,
<http://voidreflections.blogspot.com> Blog
 
-----Original Message-----
From: Mike Grundvig [mailto:mike@electrotank.com] 
Sent: 01 September 2006 15:28
To: mina-dev@directory.apache.org
Subject: Re: large messages over datagram socket
 
As soon as you start implementing guaranteed delivery and packet spanning 
with UDP, you might want to take a serious look at TCP again. It's a great 
deal of work to implement and if a re-delivery is required, it will often be

slower then TCP. Basically, the advantages of UDP are lost quickly once the 
packets get loaded down with extras needed for custom protocols. This is why

most UDP systems are based on a fire-and-forget mentality (like video 
streaming or FPS games).
 
If you have to use UDP for some other reason, completely ignore me :). 
Sadly, I'm still getting my head around MINA and so I don't have any 
specific implementation advice. Good luck!
 
Michael Grundvig
Electrotank, Inc
http://www.electrotank.com
 
 
----- Original Message ----- 
From: "Newcomb, Michael-P57487" <Mi...@gdc4s.com>
To: <mi...@directory.apache.org>
Sent: Friday, September 01, 2006 9:15 AM
Subject: large messages over datagram socket
 
 
Can you give me some clues as to how to implement this? I realize that
portions of messages could get lost, so, how would you recommend
implementing a 'best effort' type of service where large messages are
split and sent, then reassembled if all of them make it, and dropped
after some time if all of them don't...
 
Would this be a candidate for an IoFilter?
 
Also, Niklas mentioned MINA 0.9, is that a release somewhere or is that
what is in HEAD?
 
Thanks,
Michael
 

Re: large messages over datagram socket

Posted by Mike Grundvig <mi...@electrotank.com>.
As soon as you start implementing guaranteed delivery and packet spanning 
with UDP, you might want to take a serious look at TCP again. It's a great 
deal of work to implement and if a re-delivery is required, it will often be 
slower then TCP. Basically, the advantages of UDP are lost quickly once the 
packets get loaded down with extras needed for custom protocols. This is why 
most UDP systems are based on a fire-and-forget mentality (like video 
streaming or FPS games).

If you have to use UDP for some other reason, completely ignore me :). 
Sadly, I'm still getting my head around MINA and so I don't have any 
specific implementation advice. Good luck!

Michael Grundvig
Electrotank, Inc
http://www.electrotank.com


----- Original Message ----- 
From: "Newcomb, Michael-P57487" <Mi...@gdc4s.com>
To: <mi...@directory.apache.org>
Sent: Friday, September 01, 2006 9:15 AM
Subject: large messages over datagram socket


Can you give me some clues as to how to implement this? I realize that
portions of messages could get lost, so, how would you recommend
implementing a 'best effort' type of service where large messages are
split and sent, then reassembled if all of them make it, and dropped
after some time if all of them don't...

Would this be a candidate for an IoFilter?

Also, Niklas mentioned MINA 0.9, is that a release somewhere or is that
what is in HEAD?

Thanks,
Michael