|
As per google, MTU(Maximum transmission unit) can have maximum value of 1500 bytes but I am sending more then 1500 bytes data over socket from one application to other(on differnet m/c).It is going fine. I have tried up to 3500 bytes.
Please tell that what is the maximum size of MTU and how can I find out?
Thanks in advance.
Regards,
Vishal Soni
|
|
|
|
|
what's MTU ?
This signature was proudly tested on animals.
|
|
|
|
|
Maximum transmission unit
|
|
|
|
|
The MTU effects only packet size. You can use send specifying bigger buffers as the MTU, but -i belive it's TCP's job- TCP will cut your data into ~MTU sized packets, send that over, and the receiver side will put the fragments together to "recreate" your data. Or am i missing the point here?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
I am trying to send 3500 byts.On the receiver side,I have not implemented the code to take care of fragmented packets.So both client and server application have not functionality to deal with fragmented packets.
Without this,I am able to send and receive more then 1500bytes but as per MTU,it should not get more then 1500 bytes.
So there is lot of confustion related to MTU? In which case it is linked to TCP/IP send/receive size.
Thanks and Regards,
Vishal Soni
|
|
|
|
|
Vishal Kumar Soni wrote: So both client and server application have not functionality to deal with fragmented packets.
That's fine, since TCP/IP does it for you.
Vishal Kumar Soni wrote: Without this,I am able to send and receive more then 1500bytes but as per MTU,it should not get more then 1500 bytes.
So there is lot of confustion related to MTU? In which case it is linked to TCP/IP send/receive size.
Possibly packet fragmentation is an internal detail, hidden to the application layer.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Vishal Kumar Soni wrote: So both client and server application have not functionality to deal with fragmented packets.
Your code doesn't, but the code **you call** does. I bet your code doesn't perform checksums on the data you send either - doesn't mean that doesn't happen (the ethernet layer will do that). I bet your code doesn't work out which computers your data should go through to get between client and server either - again, that doesn't mean that it doesn't happen.
Vishal Kumar Soni wrote: So there is lot of confustion related to MTU?
Not really. Look at Wikipedia's page on MTU[^] - it quite clearly says that the MTU is the maximum size of data packet that can be transmitted by a layer of a communication protocol. Looking at the table of MTUs on that page, you can see that the MTU size depends on the transport you're using. Imagine you have this link to your server:
Client <-- <small>Wireless (802.11)</small> --> Gateway <-- <small>Ethernet</small> --> Gateway <-- <small>FDDI</small> --> Server
There are three different transports with three different MTUs (802.11=2272 bytes, Ethernet = ~1500, FDDI = 4500). Without an underlying layer that automatically adjusts for those different MTUs, your code would have to handle it all.
As ever with networking questions, I would recommend you download and become familiar with the IBM Networking Redbook[^].
|
|
|
|
|
As CPallini said, you don't need to fiddle with fragmentation. You just need to Send and Recv, fragmentation is done by the TCP/IP layer, also it ensures you that you get your data in the same order you sent it, so don't worry about "puttinng your fragments together in the right order" on any side.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Thanks for reply.
This problem started from live system at customer side.Sender application is sending 1800 bytes on socket but reciever side is receiving only 1460 bytes.Then one of my senior colleague asked me that it MTU problem so we need to change our implemataion.
|
|
|
|
|
Vishal Kumar Soni wrote: Then one of my senior colleague asked me that it MTU problem so we need to change our implemataion
Hi Vishal,
I have read the other responses and mostly agree with them for 99.9% of engineers. However there are valid reasons why some network engineers choose to enable a Large MTU Network[^]. By reducing SYN/ACK cross-talk you can significantly reduces network overhead and consequently increase network throughput. There are essentially two ways to improve TCP performance... one is by increasing the MTU and the other is enabling RFC-1323[^] known as the TCP window scale option.[^]
The answer to your question is that the MTU is generally "Auto-Discovered[^]" by default. You can disable this option and enforce a specific maximum transmission packet-size, however... if there is ONE router which cannot handle the oversized packet, it will send back an ICMP error message and cause the packet to resent in smaller chunks... this is known as packet fragmentation and is very harmful for throughput.
Best Wishes,
-David Delaune
|
|
|
|
|
Hi David,
Thanks for information.
According to previous discussion, we can send more then 1500 bytes over TCP/IP socket connection without caring the MTU size.At application level we don't need to implement fragmenation and defragmentaion.
So I can continue with this?
Regards,
Vishal Soni
|
|
|
|
|
Vishal Kumar Soni wrote:
we can send more then 1500 bytes over TCP/IP socket connection without caring the MTU size.At application level we don't need to implement fragmenation and defragmentaion.
So I can continue with this?
Yes, the application level should generally be designed to fuction with disregard to packet size.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks David!
Regards,
Vishal
|
|
|
|
|
An update to this problem.
As we discussed in this thread that if we send data more then MTU size then it is supposed to handle by TCP/IP protocol.At application level,we don't need to anything.
I think lot of things depends upon network adapter setting.
So I tried to find out that why it is not working on two m/c where both client and server applications are running.Both m/c having windows 2003 server and having broadcom network adapter.
In broadcom network adapter there is proprty "LSO & Jumbo frame off". By default this property has value "LSO enabled and jumbo frame off". By changing this property to "LSO disabled & jumbo frame 3000",applications are able to send/receive the data more then 1500 bytes. but some times it is still failing.Sometimes it is able to send/receive ony 536 bytes.
Could you please tell the reason?
Thanks and Regards,
Vishal Soni
|
|
|
|
|
I have displayed a messagebox with MB_RTLREADING flag.
The string that i tried to display is some thing like: "Name(First Name)"
However I am getting the display of "(Name ( First Name"
The syntex used for the messagebox was as follows:
MessageBox(NULL,"Name (FULL NAME)","good",MB_RTLREADING );
Please suggest what setting i am missing?
|
|
|
|
|
Possibly you're missing this part of the documentation [^]
MB_RTLREADING
Displays message and caption text using right-to-left reading order on Hebrew and Arabic systems.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi
It is treating closing bracket as the line terminatior.
This can be understood by this example.
Source string: Name (First Name).
Displayed in the RTLREADING: .(Name (First Name
However
Source string: Name (First Name) is Ok.
Displayed in the RTLREADING: .Name (First Name) is OK
What i want is
Source string: Name (First Name).
Displayed in the RTLREADING: .(ame (First Name)
I need suggestion for displayed text in the above stated format.
|
|
|
|
|
piyush kumar tewari wrote: I have displayed a messagebox with MB_RTLREADING flag.
Which is not the same as having right-justified text.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
If you mean to say that the MB_RTLREADING is not the appropriate flag to use, then what can be the other options to try in this situation?
|
|
|
|
|
How about MB_RIGHT?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
i have converted my VS2005 project into VS2008 and trying to use the CMFCOutlookBar.
but the application crashes while adding the tabs.
on the contrary, if i create a new VS2008 project and use CMFCOutlookBar, everything seem to work fine.
do i have to do any changes in my converted project in order to make the outlookbar work?
thanks
|
|
|
|
|
|
Hi all,
i am developing an application to control an I/O card, read data from a serial port.
i am new to these field of programming.
i am using VC++ as my development language.
can i get some help on articles or ebooks or sample programs for doing the same??
|
|
|
|
|
Subrat Patnaik wrote: i am developing an application to control an I/O card, read data from a serial port.
Does the above mean: "my I/O card reder device is connected to the PC serial port"?
What are you doubts about?
Are you able to use the serial port API, aren't you (see, for instance [^])?
Have you the documentation of the device?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
How about this CP article[^] about programming the serial port?
It's not so difficult - the main difficulty is being sure that the remote end is doing/expecting what you are expecting/doing.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
