tcp

[Ranjeet_Singh]

When the number of byte to read over TCP is not known than which mode is best. Because in my project data to be read vary from  

100 bytes to 200000 bytes as per the requested by user.If number of bytes to be read is not fixed than i cant use standard & buffer. only option i can see is immediate, but problem is if i am using immediate mode than maximum byte i can read is 3752.

Can you tell me whats a solution ???

Thanks.

[RavensFan]

Do multiple reads within a loop.

If you don't know how many bytes to read, then have the sender tell the number of bytes being sent by sending them at the beginning of the message.  Read a few bytes to get that number, then read more bytes based on what that number is.

Look at the TCP read and write examples in the example finder.

[Ranjeet_Singh]

1. See the problem with read two times is that if after 1st read & before second read if data from another equipment comes then data will be wrong because here multiple slaves are there. 

2. Although if sender will tell me that how many bytes he is sending & if in second read operation by using standard mode i am reading that many bytes than only 2 way to terminate the communication either by timeout or by no of bytes to be read is actually read. But timeout can't be helpful because it will be -1(As this is running on server). & if number of bytes than if even one byte is also lost while communication than entire record will be lost as the program will go in infinite loop because it will be waiting for that many bytes. So this wont be reliable.

                                                        So tell me another alternative. According to me timeout read will be good & number of byte to be read i can give as maximum. So i can read variable lenght in single read only. What say   

[RavensFan]

---

@Ranjeet_Singh wrote:

1. See the problem with read two times is that if after 1st read & before second read if data from another equipment comes then data will be wrong because here multiple slaves are there. 

It's TCP/IP.  If there is more than one piece of equipment, it will have a different IP address and thus will need another, different TCP session created.

2. Although if sender will tell me that how many bytes he is sending & if in second read operation by using standard mode i am reading that many bytes than only 2 way to terminate the communication either by timeout or by no of bytes to be read is actually read. But timeout can't be helpful because it will be -1(As this is running on server). & if number of bytes than if even one byte is also lost while communication than entire record will be lost as the program will go in infinite loop because it will be waiting for that many bytes. So this wont be reliable.

                                                        So tell me another alternative. According to me timeout read will be good & number of byte to be read i can give as maximum. So i can read variable lenght in single read only. What say   

It's TCP/IP.  Bytes don't get lost.  Only packets can get lost.  TCP/IP should resend the packet automatically, but if not, you can always implement response and request resends in your protocol.  You can also implement some additional bytes in your data that will reflect if there are more packets to receive or not so you won't be waiting for packets that are never sent.

---

[Ranjeet_Singh]

1. Not exactly. All slaves will be sending continously in predefined  random interval & server will be in listening mode. Hence in record only i will come  to know that from which unit i am getting data & accordingly i will update the database. In the equipment side all the equipment will have dynamic IP address so each time the IP address will be different So wont help i think.

2. As a server & in this application this os only 1 way communcation. Hence server wont be able to send the data. So this communication wont work. What u suggested is good so can you please elaborate the last line.

[smercurio_fc]

Is it predefined or is it random? I don't know what predefined random means. The communication has to have a protocol. That means your talkers and your listener have to agree on a specific way to transmit the data. TCP/IP acts a transport mechanism. It cannot magically make this work. If the talkers provide the number of bytes to send at the beginning then you know how many bytes you need to read. Have you looked at the shipping example? If so, you'd note that the communication protocol there sends an I32 (which is 4 bytes) to indicate the number of bytes of data. Thus, the first TCP/IP Read reads exactly 4 bytes to get that value. It then feeds that into the next TCP/IP Read so it knows how many bytes to read. This is a very simple and effective communication protocol. Is there a reason why you cannot use this scheme?

P.S. I noticed you have "Knights of NI" in your signature. Is that an honorary title?

[Ranjeet_Singh]

Predefined & random - In my application server will read the 2 type of data one will be at fixed interval & size of that will be 200 bytes in the interval 10 min (say) & this interval time will be fixed i.e. server will continue read in this 10 min interval hence predefined & fixed & other in another option in which user will request the data. So i dont know the interval so random & size if data will vary from user to user as per the request.

If my talker will send the number of byte to be read than i want two consecutive read this is what i want to avoid. because in my second read option if i will mention the number of byte to be read than if even 1 packet is lost during communication than my program will be infinite loop because in that case only & only if i received that my bytes than only i can terminate my program otherwise keep on waiting for that byte.

What is this shipping example ?

[Ranjeet_Singh]

Thanks for your reply.

 I got one more question for you. Can you tell me that how to verify that session is active or lost. Suppose that i am reading data that will take 10 minuntes to complete. Suppose that in between network is lost but i am continue waiting for the data. If somehow i can figured it out that network is lost than this will be great.

Please suggest me as soon as possible.

Thanks

[Mark_Yedinak]

Each device shuold have it's own connection to the server. You cannot have two devices connected to a single TCP connection. Depending on how your server is implemented it may only allow one client at a time but each and every client will get it's own connection. You should not be mixing data from client unless your server only has a single task processing the data. If this is the case when you hand data to the processing task it would be up to you to include some identifying information to indicate which client it was from.

Also, if you don't know the number of bytes you can read data continuously and use the timeout error to indicate the data is complete. This is not fool proof but it doesn work reasonably well if you know a minimum amount of time between data responses. If you know your data will be sent once a second for example, you can set a timeout on th eread of something like 250 ms. Keep reading data until you get the timeout. When the timeout occurs assume that particular data set is complete. Of course it works much more reliably if the sender lets you know how much data it is sending. Standard will work just fine BTW if you use the approach I suggested.

[Ranjeet_Singh]

Yes there are multiple client & at a time only one client will be connected to the server. After receiving the data server can identify that from which client this data belongs to.

 You said - "If you don't know the number of bytes you can read data continuously and use the timeout error to indicate the data is complete."     

                                           Can you please tell me how to implement this because i need to read continously the data as the program is running on the server as this is the TCP i cant predict the read time i.e timeout. And according to me this is wrong approach to check the timeout & if this occure than say data is complete because data read will vary from 200 bytes to 2000000 bytes & for each time client cant tell the TIMEOUT.