tcp packets

[jay090909]

Hi,

      Thanks for the idea, I need to know how to implement the above using TCP read\Write vi in laview . 

[LamD.]

Hi Jay,

did you already take a look at the examples shipping with LabVIEW. You can find them by navigating to Help -> Find Examples:

Just search for TCP/IP you will find several useful examples on how to handle TCP/IP communication with LabVIEW.

If you still have questions then, just ask. 

Lam

[jay090909]

Hi,

   I wanted to know maximum packet size u can send via tcp\Ip . Some docs tell 1500 bytes some tell more. What' actual size? How to detemine the packet size?

[Mark_Yedinak]

TCP itself supports a maximum packet size of 6553 which is the largest window size you can define. However using teh TCP VIs there is no set limit. You can pass a buffer to the TCP write that is several megabytes. The TCP stack will handle fragmenting it and sending it in chunks. The 1500 number you heard is the maximum Ethernet packet size. TCP packets will be fragmented to fit within the Ethernet frame. The actual maximum TCP data within a single Ethernet frame is actually 1460.bytes. From an application standpoint you don't really need to worry about the TCP data size.

[jay090909]

Hi, 

         Is it 65535 or 6553.

[Mark_Yedinak]

---

@jay090909 wrote:

Hi, 

         Is it 65535 or 6553.

---

Yes, the maximum window size in a TCP packet is 65535. Sorry about the typo.

[SteveChandler]

---

@Mark_Yedinak wrote:

TCP itself supports a maximum packet size of 6553 which is the largest window size you can define. However using teh TCP VIs there is no set limit. You can pass a buffer to the TCP write that is several megabytes. The TCP stack will handle fragmenting it and sending it in chunks. The 1500 number you heard is the maximum Ethernet packet size. TCP packets will be fragmented to fit within the Ethernet frame. The actual maximum TCP data within a single Ethernet frame is actually 1460.bytes. From an application standpoint you don't really need to worry about the TCP data size.

---

Also the 1500 packet size is configurable. I don't know if that is important for this discussion but I wanted to throw that in.

[Mark_Yedinak]

---

@SteveChandler wrote:

---

@Mark_Yedinak wrote:

TCP itself supports a maximum packet size of 6553 which is the largest window size you can define. However using teh TCP VIs there is no set limit. You can pass a buffer to the TCP write that is several megabytes. The TCP stack will handle fragmenting it and sending it in chunks. The 1500 number you heard is the maximum Ethernet packet size. TCP packets will be fragmented to fit within the Ethernet frame. The actual maximum TCP data within a single Ethernet frame is actually 1460.bytes. From an application standpoint you don't really need to worry about the TCP data size.

---

Also the 1500 packet size is configurable. I don't know if that is important for this discussion but I wanted to throw that in.

---

Yes, you can configure some switches to use jumbo frames but this can be problematic at times if you have older equipment. It is possible for some data to get dropped. The standard Ethernet frame is always a safe bet.

[jay090909]

Hi,

     I'm really confused regarding the architectures in client Server application. I would like to know which would be the better and easz to implement architecture in client server communication. My application needs 3 buttons (Start , End and shutdown) commands for the server at the first point and later would be getting data from server and sending data from client.

I need to know does state machine works in this case?

 I got a architecture from the internet which resembles the above case, I would like to know is it a producer consumer loop.

[Mark_Yedinak]

That code will not work since you have two inifinte loops in parallel with your loop with the TCP VIs. Once in that case of the case statement you will never exit it. Your program will hang. It is also not a good idea to implement greedy loops which both of your infitinte loops are. In most cases a loop should have some code that will allow the scheduler to evaluate if other code can run. The simplest way to do this is to put a Wait 0 in the loop. However other VIs such as a Dequeue VI, a Wait on notfiction, an Event Structure all will allow the scheduler to check if other code can run.

As for a server/client architecture you could take a look at this example.