FW 1.0.5.2 & multi connection

Hello Team,

well i just notice this new version !
i read “Added TCP Server Multi Connection” : does it mean now that several browsers can access simultaneous to the wizfi250 web server on the same port ?
please can you share some example , links or help to check how use this feature ?

the FSOCK command is not update ( [url]http://wizwiki.net/wiki/doku.php?id=products:wizfi250:wizfi250pg:at_command_set#at_fsock[/url])

thanks, best regards

Hello,

Actually “TCP Server Multi Connection” is possible on Station mode.

Following shown “Multi Connection” example.

[code]Set Factory Default
[OK]
WizFi250 Version 1.0.5.2 (WIZnet Co.Ltd)
[OK]
WizFi250 Version 1.0.5.2 (WIZnet Co.Ltd)
AT
[OK]
AT+WSET=0,DIR-815_Wiznet
[OK]
AT+WSEC=0,WPA2,12345678
[OK]
AT+WNET=1
[OK]
AT+WJOIN
Joining : DIR-815_Wiznet
Successfully joined : DIR-815_Wiznet

[Link-Up Event]
IP Addr : 192.168.1.107
Gateway : 192.168.1.1
[OK]
AT+FSOCK=9,1
[OK]
AT+SCON=O,TSN,5000,0

[LISTEN 0]
[OK]

[CONNECT 0]

[LISTEN 1]

[CONNECT 1]

[LISTEN 2]

[CONNECT 2]

[LISTEN 3]

AT+SMGMT=?
Number of Sockets : 4 (SCID/Mode/Remote/Local/DataMode)
0/TSN/192.168.1.106:63543/5000/0
1/TSN/192.168.1.106:63549/5000/0
2/TSN/192.168.1.106:63555/5000/0
3/TSN/0.0.0.0:0/5000/0
[OK][/code]

Note that WizFi310 supports both Soft AP mode and Station mode.

Thank you.

Best regards.

hello

well please can you maintain update a pdf file with all news commands and options ?
the wiki page is not update. several options/definitions are missing.

my application use one TCPserver, one TCPclient and several UDP sockets.
i run in STA mode, with multi socket activated (AT+FSOCK=9,1).

when the wizfi module receive a header (when a web browser access to the module), we receive something like that :
“{0,192.168.0.216,59834,422} …HTTP header request …”
that mean on socket 0, from IP 192.168.0.216, on port 59834 and data header is 422 bytes

or if another web browser do same, we receive an header like
“{1,192.168.0.216,47312,416} …HTTP header request …”
that mean on socket 1, from IP 192.168.0.216, on port 47312 and data header is 416 bytes

why the port numbers are different ?

the wizfi module open the TCP server on a specified port : AT+SCON=O,TSN,80,0 so port 80.
how we can know that we need to reply the web page data ? do we need at this time analyses and parse the data header to know what to reply ?
and as we need to use TCP server and TCP client, in these both case we will receive some HTTP header … not easy to know what to reply !

thanks, regards

Hello,

As you mentioned, WizFi seem to be currently running as server.
The port number must be different.
That is client’s port number that connect to WizFi.

And thanks for pointing out. We will update that information in the near future.

Thanks. Best regards.

Cliff,

please can you reply to my question !?

the W250 module is configured as explain previously : 1 TCP server, 1 TCP client and several UDP sockets.
we enable multiple connection AT+FSOCK=9,1

what is the right method to know what we need to reply to the incoming request ?

  • we can’t use socket number, as it will be different for each access
  • we can’t use port number, as it come from the client

==> so, do we parse the data header and analyze it to define if we need reply with HTML data ?

previously, without multiple connection enable, we used the socket number to know what to reply. but now, for the TCP server, the socket number change on each client request !
now, both TCP server and client sockets may provide some HTTP request !

thanks, regards

Hello,

Actually, as mentioned above, I don’t know what point is problem exactly.
Can you send me a more detailed description of the situation and an AT command log file for a definite answer?

Thanks, regards

in fact, something is strange !
with multiple connection enable, when we receive a request to serve, we see some “asynchronous” message before the end of our reply.

the module send the data header to our CPU. we analyze it then we start the process to reply : prepare the data to reply, start to send with AT+SSEND, then before the end of this command, we receive others kind of message (like [CONNECT…)
a new request is send to our CPU before we send all data of the first one and wait for [OK]

i don’t know if that is a bug in the module or not, but it will be not easy to manage this kind of method. we don’t use a real time OS !

thanks, regards

Hello,

I think, following link will be helpful to you.
This is mbed library for WizFi250.
[url]WizFi250Interface - This is WizFi250 library for NetworkInterfaceAPI … | Mbed

It will be helpful to check above library code and focus on WizFi250_at.cpp and WizFi250_msg.cpp source code.

Thanks, best regards.

well i’m not a fluent cpp user !
what may be useful ? … the fact that a circular buffer is employed ?

thanks

Yes, we think that.
It is recommended to use the buffer because the module looks fine.
And even if you don’t know cpp, that library code will help you entirely.

Thanks.

Hello Cliff,

well please can you provide more information about “this buffer” …
after review the code, i don’t understand what may be useful !
we already write our own driver.

the problem is that the module send some command after we start the procedure to send some data to the module.
we send AT+SSEND and send our data. but instead of receiving the [OK], sometime we receive information from another socket !

the module don’t wait the end of the SSEND command, to send some new request to the CPU.

thanks, regards

Hello,

Since you didn’t use the buffer, we think that had a problem.
Is it rigit?
If it is ‘no’, we don’t know what part is problem.
There were no specific problems with the module in inner module test.
We don’t know your testing environment.
So, to solve your problem, please inform me that logfile for your present and a detailed information.

Thanks, best regards.

for sure i use a buffer to receive the bytes from the W250 module !
we use too the hardware handshake of course.

we can’t provide a log file as you expect. this is not easily to reproduce the problem with a simple terminal !
the problem is when the module is configured as TCP server, multi connection enabled.
when a client request a web page, we receive several request on different socket. - right -
but when we start to reply to a request ( with AT+SSEND ), after we sent all the data, we expect [OK]
but sometime, we receive a new request/command before that [OK] !

thanks

I’d like to know if the current buffer is a buffer for RX data only.
If it is so, I suppose you should configure additional buffer.

When you reply to a request(with AT+SSEND), new request/command have to store to the buffer before that [OK]
And then perform request/command to stored in additional buffer after that request(with AT+SSEND) is performed.

Thanks, best regards

we use 2 buffers :
1 for RX data
1 for RX command

[CONNECT… ] and [OK] are considered as commands.
so when we wait for [OK] in the command buffer, we receive [CONNECT…] instead of [OK]

i’m not sure to right understand what you try to explain !

but can’t you simply don’t send any new command when one is active/running ?
when our CPU send the AT+SSEND, start a timeout then until the end of timeout or the end of the data, you don’t allow to send new command !
(as i understand, there is already this timeout … 2 seconds nope ?)

thanks

Hello,

We suppose it is data lost problem.
We did several tests and when data of many bytes is transmitted, sometimes data was lost.
So when sending data through serial with AT+SSEND, we propose to use the “HardWare Flowcontrol”.

Like this :
AT+USET=115200,N,8,1,HW

For your information, “Hardware Flowcontrol” is check the receiver’s buffer status to CTS and RTS.

Thanks, regards.

hi,

HW flow control is enable since the beginning of the project !!

So team,

what is the solution to my problem ?

does anybody use successfully the multiple connection with fw 1.0.5.2 ?
our product serve a "big"web site ( several html page with css, images and javascript).

thanks for any help or advise, regards

Hello,

First of all, I’m so sorry for late reply.
Test is ongoing now, based on you mentioned.
There is a lack of information and it takes a little time to figure out the problem.
I will contact you as soon as I know the problem.

Thanks, regards.

Cliff,

you are welcome to ask any more details.

waiting your conclusions, regards