TCP/IP Socket data sending and time

[chiduprakash]

Dear Members,

I am using TCP/IP Socket profile in my Q24Plus OpenAT application using Wip plugin.

I am sending about 3351 bytes of data to the server using wip_write() function as below.

nwrite=wip_write( my_wip_channel, history_data_str,strlen(history_data_str));
wip_close( (wip_channel_t) my_wip_channel);

my wip_write function returns the value exact no. of bytes i am sending (ex nwrite=3351). But on server side i am receiving only around 1.6 or 1.7 k bytes of data.

After observing this i given 2 seconds gap between wip_write() and wip_close() . Now it is sending whole data to the server properly.

Now I want to know how to check/determine the time delay between wip_write() and wip_close() for successfully sending of data to the destination server and also can i get any acknowledgment or events from wip functions for successfully transfer of data to the server.

What is the maximum length of data can i send using Wip_write()?

Please suggest and advise.

[Madouc]

if it is possible i would send an acknowledgement from the server, and then close the channel.
there is no way of knowing when (or even if) the data is fully transmitted to the server at the client side.

as for the maximum amount of bytes to send in one go,
i think that depends on your buffer-settings. (and the amount of bytes still in the buffer ofcourse)

[chiduprakash]

i think that depends on your buffer-settings. (and the amount of bytes still in the buffer ofcourse)

[/quote]
But wip document shows buffer length type U32.

what does it mean?

[awneil]

@chiduprakash

But wip document shows buffer length type U32.

what does it mean?

It simply means that an unsigned 32-bit data type is used - it does not say anything at all about the maximum value of that parameter…

[Madouc]

@chiduprakash

But wip document shows buffer length type U32.
what does it mean?

U32 is Wavecom ‘slang’ for an unsigned 32bits number.

for the practical implementation this means nothing, the amount of memory you can assign to your send-buffer is depending on how much memory you have available.

[chiduprakash]

@chiduprakash

i think that depends on your buffer-settings. (and the amount of bytes still in the buffer ofcourse)

I really did not understood on buffer-settings.

[Madouc]

@chiduprakash

I really did not understood on buffer-settings.

@wip connectivity development guide - 6.1.5 Options

WIP_COPT_SND_BUFSIZE
Size of the emission buffer associated with a socket.
Default: depends on the protocol.

-edit- quoted wrong portion

[chiduprakash]

@wip connectivity development guide - 6.1.5 Options

WIP_COPT_RCV_BUFSIZE
Size of the reception buffer associated with a socket default: depends on the protocol.

[/quote]
My application dealing with sending not receiving and TCP/IP socket profile.

Please see the code

r = wip_bearerOpen( &wip_bearer, "GPRS", evh_bearer, NULL);
		r = wip_bearerSetOpts( wip_bearer, WIP_BOPT_GPRS_APN, apn_name,
                         WIP_BOPT_LOGIN,       "",
                         WIP_BOPT_PASSWORD,    "",
                         WIP_BOPT_END);
r = wip_bearerStart( wip_bearer);
void evh_bearer( wip_bearer_t b, s8 event, void *ctx)
{
	switch (event)
	{
	case WIP_BEV_IP_CONNECTED:
          socket=wip_TCPClientCreate( ip_address,port_no, (wip_eventHandler_f) &evHandler, &state);
           break;
       }
       
}

[Madouc]

@chiduprakash

@wip connectivity development guide - 6.1.5 Options

WIP_COPT_RCV_BUFSIZE
Size of the reception buffer associated with a socket default: depends on the protocol.

My application dealing with sending not receiving and TCP/IP socket profile.

I quoted the wrong option. the discripton for the send buffer (almost) the same.
just read the documentation.
you can use wip_getOpts to get the actual size of the buffer.

[davidc]

Hiya,

Irrespective of the buffer size specified by the wip_setOpts(), there is a hard packet size of 1500 bytes for GPRS (which WIP sits on) packets. See Section 3.9.7 of the ADL user guide (top of page 102 in the R7.4 version). I suspect that this 1500 bytes also include packet headers/trailers/checksums etc - so your maximum data per paket will probably be less than 1500 bytes (1492 rings a bell for some reason).

What might be happening is that you are submitting a lot (well, over 1500 bytes) to the wip_write() call - which can internally buffer all your data. However, you are then calling wip_close() before all the data has been shifted out across the GPRS link, and the socket is being closed. That’s probably why your server end is not getting all the data.

@Madouc

if it is possible i would send an acknowledgement from the server, and then close the channel.
there is no way of knowing when (or even if) the data is fully transmitted to the server at the client side.

Exactly. That’s what HTTP does.

If you are going stream data (like audio or video or other data stream where dropped data doesn’t matter), use UDP and just shift your data out as fast as is required. Otherwise, use TCP and layer your own ACK/NAK protocol inside your data packets.

ciao, Dave

[chiduprakash]

I quoted the wrong option. the discripton for the send buffer (almost) the same.
just read the documentation.
you can use wip_getOpts to get the actual size of the buffer.

Yes gone through it the description is same as you told.
I will work with these getOpts functions.

[chiduprakash]

See Section 3.9.7 of the ADL user guide (top of page 102 in the R7.4 version).

I have ADL user guides (v3.13 and V6.11) where can i get R7.4 Version?

If you are going stream data (like audio or video or other data stream where dropped data doesn’t matter), use UDP and just shift your data out as fast as is required. Otherwise, use TCP and layer your own ACK/NAK protocol inside your data packets.

My data stream is not audio or video and should reach exactly the same size.
Our server is receiving data from 1000 modems on the same port. each modem sending data 200 bytes at 15 minutes interval (not all at the same time (no RTC)based on ADL timers).
So after sending the data i have to make the channel free asap so that server will be free to recieve data from another modem. Making ACK/NAK protocol may increase the time offset (nmodemes * ACK/NACK time).

Sending 3.5k data will be only once in a day per modem.

[Madouc]

@chiduprakash

See Section 3.9.7 of the ADL user guide (top of page 102 in the R7.4 version).

I have ADL user guides (v3.13 and V6.11) where can i get R7.4 Version?

you don’t have a section 3.9.7 in your doc’s?

@chiduprakash

If you are going stream data (like audio or video or other data stream where dropped data doesn’t matter), use UDP and just shift your data out as fast as is required. Otherwise, use TCP and layer your own ACK/NAK protocol inside your data packets.

My data stream is not audio or video and should reach exactly the same size.
Our server is receiving data from 1000 modems on the same port. each modem sending data 200 bytes at 15 minutes interval (not all at the same time (no RTC)based on ADL timers).
So after sending the data i have to make the channel free asap so that server will be free to recieve data from another modem. Making ACK/NAK protocol may increase the time offset (nmodemes * ACK/NACK time).

Sending 3.5k data will be only once in a day per modem.

The port you connect on is only a connecting port.
The actual data-transfer usualy takes plase to a randomly chosen port (how else would web-servers be able to operate?)
I think you can even connect all the modems at the same time and even keep them connected.

Are you sure your modems keep that same port open?
Because i find that hard to believe.

even if you feel you might have a problem, sending 1k (1000x 1 byte) every 15 minutes isn’t going to be a problem.

[davidc]

Hiya,

@chiduprakash

I have ADL user guides (v3.13 and V6.11) where can i get R7.4 Version?

Wavecom numbering can be a little cryptic sometimes. I’m referring to the version contained in the OpenAT 2.30 package, along with firmware revision R7.4. You can get the latest versions from the Products/Downloads section of the Wavecom website after you have logged in with a Developer login.

@chiduprakash

So after sending the data i have to make the channel free asap so that server will be free to recieve data from another modem.

Hmm, I think that you’re missing something here about TCP servers. It’s my (limited) understanding from writing a couple of (linux) based server apps, that the server listens on a socket for inbound connections. Once the inbound connection is accepted, another data socket (on another port) is negotiated between the server and the client and all further comms between server and that client occurs over the new port. This allows the original port to be put back into listening mode for the next incoming connection - and the data transfer to take as long as is required.
I’m not sure at which point in the TCP protocol that this ‘port shuffle’ takes place, but I recall that was pretty transparent to me as the application programmer. I wrote a simple multi-threaded app to handle the multiple, simultaneous inbound connections. You don’t have to do it multi-threaded though - you can also fork() (in unix - not sure about windows) your app each time you get a new inbound connection.

It sounds like you need to do a bit of work on your server end to let the server handle multiple simultaneous connections. If you can’t do this, your WIP code will also have to deal with the server not accepting connections because it’s busy - 1000 connections every 15 minute (900 seconds) means that your server has to set up a connection, transfer data, tear down connection and then get ready for the next inbound connection in 900 milliseconds. You’re also transferring data at 44kbits/sec (max speed of GPRS).

Look to your server and make it handle multiple, concurrent connections - or change to a protocol that will let you do this (i.e. HTTP & Apache would probably eat this sort of connection on a reasonable PC).

Just my 2 cents.

ciao, Dave

[chiduprakash]

The port you connect on is only a connecting port.
The actual data-transfer usualy takes plase to a randomly chosen port (how else would web-servers be able to operate?)
I think you can even connect all the modems at the same time and even keep them connected.

You are right i checked practically by keeping connected to the port and not closing wip_close() for 10 minutes i saw other Modems data coming between this 10 minutes on the Server console ( monitoring for receiving of data from modems).

Are you sure your modems keep that same port open?
Because i find that hard to believe.

I am not sure i just imagined.
But practically when i checked by sending 100 bytes of data 100 times using Timer_ticket of 518ms i am receiving data properly till that time i am not doing wip_close() and i received data properly on hyper terminal. So this means that port is kept opened up to my 100 transactions. Also i observed time taken by hyper terminal is about 34 seconds to receive 109100 bytes.