Search Results

Search found 5 results on 1 pages for 'wsaasyncselect'.

Page 1/1 | 1 

• Winsock WSAAsyncSelect sending without an infinite buffer

  - by Xexr

  Hi, This is more of a design question than a specific code question, I'm sure I am missing the obvious, I just need another set of eyes. I am writing a multi-client server based on WSAAsyncSelect, each connection is made into an object of a connection class I have written which contains associated settings and buffers etc. My question concerns FD_WRITE, I understand how it operates: One FD_WRITE is sent immediately after a connection is established. Thereafter, you should send until WSAEWOULDBLOCK is received at which point you store what is left to send in a buffer, and wait to be told that it is ok to send again. This is where I have a problem, how large do I make this holding buffer within each connections object? The amount of time until a new FD_WRITE is received is unknown, I could be attempting to send a lot of stuff during this period, all the time adding to my outgoing buffer. If I make the buffer dynamic, memory usage could spiral out of control if for whatever reason, I am unable to send() and reduce the buffer. So my question is how do you generally handle this situation? Note I am not talking about the network buffer itself which winsock uses, but one of my own creation used to "queue" up sends. Hope I explained that well enough, thanks all!

  Read the article

• WinSock best accept() practices

  - by Meta

  Imagine you have a server which can handle only one client at a time. The server uses WSAAsyncSelect to be notified of new connections. In this case, what is the best way of handling FD_ACCEPT messages: A Accept the connection attempt right away but queue the client until its turn? B Do not accept the next connection attempt until we are done serving the currently connected client? What do you guys think is the most efficient?

  Read the article

• Returning from dll (Asynchronous sockets)

  - by Juha

  I am trying to do a simple http-server in (c++) dll-file that I can use from managed (C#) application with P/Invoke. I was trying to do this with asynchronous functions (WSAAsyncSelect() and stuff), so that I could manage server by calling functions inside dll whenever needed and after that it would return to my main program. Now I'm not sure if that is even possible. It seems that "main function" in dll, the function that starts the server, has to include message loop or something and since it's a loop, it doesn't return from dll ever. Could I somehow do this message stuff in my managed application and call some function in dll when there is something to do? Or is it even possible to do this stuff in one thred? I would really like to avoid all concurrency stuff. The dll looks now basicly the same as here, main function is the one that I call from managed C# program and would like to return to there after calling the function. http://www.winsocketdotnetworkprogramming.com/winsock2programming/winsock2advancediomethod5b.html I'm quite noob in windows programming, and never even heard of this message-queue or message-loop.

  Read the article

• c++ connect() keeps returning WSATIMEDOUT over internet but not localy

  - by KaiserJohaan

  Hello, For some reason, my chat application always gets WSATIMEDOUT when trying to connect to another person over the internet. int len_ip = GetWindowTextLength(GetDlgItem(hWnd,ID_EDIT_IP)); char ipBuffer[16]; SendMessage(GetDlgItem(hWnd,ID_EDIT_IP),WM_GETTEXT,16,(LPARAM)ipBuffer); long host_ip = inet_addr(ipBuffer); int initializeConnection(long host_ip, HWND hWnd) { // initialize winsock WSADATA wdata; int result = WSAStartup(MAKEWORD(2,2),&wdata); if (result != 0) { return 0; } // setup socket tcp_sock = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP); if (tcp_sock == INVALID_SOCKET) { return 0; } // setup socket address SOCKADDR_IN tcp_sock_addr; tcp_sock_addr.sin_family = AF_INET; tcp_sock_addr.sin_port = SERVER_TCP_PORT; tcp_sock_addr.sin_addr.s_addr = host_ip; // connect to server if (connect(tcp_sock,(SOCKADDR*)&tcp_sock_addr,sizeof(tcp_sock_addr)) == SOCKET_ERROR) { return 0; } HRESULT hr = WSAGetLastError(); // set socket in asynchronous mode if (WSAAsyncSelect(tcp_sock,hWnd,SOCKET_TCP, FD_READ | FD_WRITE | FD_CONNECT | FD_CLOSE) == SOCKET_ERROR) { return 0; } return 1; } For some reason it works perfectly fine on local network between computers, but totally screws up over the internet. WSATIMEDOUT is always returned (not connection refused, so its not a port problem). It makes me believe something is wrong with the IP but why on earth can it work on local addresses (like 192.168.2.4) Any ideas? Cheers

  Read the article

• XmlHttpRequest bug?

  - by valdo

  Hello all. I'm writing a program that among other things needs to download a file given its URL. I'm too lazy to implement the Http/Https protocols manually, so that I needed some library/object/function that'll do the job. Critical requirement: The download must be asynchronous. That is, the thread that issued the download must be able to do something else "while" downloading the file, plus the download must be able to be aborted anytime without any barbaric side effects (such as internal call to TerminateThread). Nice-to-have requirements: Should be able to download the file "into memory". Means - read the contents of the file as they arrive, not necessarily save it into some "file system" file. It'd be nice to have some convenient Win32 progress notification mechanism (waitable event, semahpore, completion port, etc.), rather than just periodically polling the download status. I've chosen the XmlHttpRequest COM object to do the work. It seemed to work fine enough, plus it supported asynchronous mode. However I noticed that after some period it just stops working. That is, after several successful file downloads it stops downloading anything. I periodically poll it to get its status, it reports "in-progress", but nothing actually happens, and there's no network activity. Moreover, when the same process creates another instance of XmlHttpRequest object to perform new downloads - the effect is the same. The object reports "in progress", whereas it doesn't even try to connect to the server (according to network sniffers and system TCP state). The only way to make this object work back is to restart the process. This makes me suspect that there's a sort of a bug (sorry, I meant undocumented feature) in the object. Also it's not a bug at the level of an individual object, since the problem persists when the object is destroyed and another one is created. It's probably some global state of the DLL that implements this object. Does anyone know something about this? Is this a known bug? I'm pretty sure there's no chance that I have another bug in my code, because of which it seems to me to be the bug is in the XmlHttpRequest. I've done enoughtests and spent time with the debugger to conclude without reasonable doubt that it's just the object stops working. BTW, while the object should work, I do all the waiting via MsgWaitXXXX API calls. So that if this object needs the message loop to work properly (for instance, it may create a hidden notification window and bind it to a socket via WSAAsyncSelect) - I give it the opportunity.

  Read the article

1