Think the 64KB limit is solved. Added this to web.config on server, seems
to work. 2 things I hadn¹t seen before. 1st was the contract set to
Microsoft.Synchronization.Services.IRequestHandler, second, the
webHttpBinding option (been using basicHttpBinding). I ran an upload of
over 71KB and it worked.
All settings under binding name are same as I use for normal business
services.
<system.serviceModel>
<services>
<service name="SalesScope.SalesScopeSyncService">
<endpoint address = ""
binding="webHttpBinding"
bindingConfiguration="higherMessageSize"
contract="Microsoft.Synchronization.Services.IRequestHandler"/>
</service>
</services>
<bindings>
<webHttpBinding>
<binding name="higherMessageSize"
maxBufferSize="2147483647" maxBufferPoolSize="524288"
maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="2147483647"
maxStringContentLength="2147483647" maxArrayLength="2147483647"
maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
</binding>
</webHttpBinding>
</bindings>
</system.serviceModel>
On 7/7/11 12:25 PM, "Abe Gillespie" <[email protected]> wrote:
>Yep, pretty much. You said these are pure posts so you're kinda
>rolling-your-own web service? In any case, if it were a standard ASMX
>or WCF web service I'd have something like the following. Translate
>these into whatever scenario you're working with:
>
>string StartUpload(int totalSize) - returns the file token
>void SendChunk(string fileToken, byte[] data)
>
>The server could then simply begin processing once totalSize is met or
>you could have:
>
>void CommitUpload(string fileToken)
>
>or some such.
>
>You could make it even more robust by adding something like:
>
>string CheckStatus(string fileToken)
>
>-Abe
>
>On Thu, Jul 7, 2011 at 12:06 PM, Mark Handzlik
><[email protected]> wrote:
>> Thanks Abe:
>> It is an Xml transfer of device database changes to keep a master
>>database
>> in-sync. Device sends xml changes up then server send its changes down.
>> Same service. Down transmit always works regardless of size. Up Transmit
>> works if under 64k fails over.
>>
>> Good idea on work around. File Token you refer to, are you saying
>> basically send 64K at a time to a server method. Server responds blindly
>> OK to these chunked sends. Server cache's until it receives the "all
>> Done" token that has total size, then server compares and responds with
>> final OK?
>>
>> On 7/7/11 11:56 AM, "Abe Gillespie" <[email protected]> wrote:
>>
>>>If you can't find the issue you can always go with a work-around. I'm
>>>assuming this is some sort of file upload? If so, initiate a transfer
>>>from the client with the file size and return a file token. Then send
>>>chunks to the server filling up a buffer keyed to that file token. It
>>>shouldn't be too much effort to do so. If you have to support legacy
>>>clients then just simply add a new upload method that only your iOS
>>>clients will use.
>>>
>>>-Abe
>>>
>>>On Thu, Jul 7, 2011 at 10:49 AM, Mark Handzlik
>>><[email protected]> wrote:
>>>> Thanks for reply Jason,
>>>> WCF binding not in play to my knowledge as this is a pure POST. I can
>>>>get
>>>> large sizes of data down from server but a send error 14's on anything
>>>>> 64K
>>>> Shared App pool is where this site is pointed, .net 3.5 sp1 installed
>>>>and
>>>> IIS7
>>>> From: Jason Awbrey <[email protected]>
>>>> Date: Thu, 7 Jul 2011 10:39:53 -0400
>>>> To: Mark Handzlik <[email protected]>
>>>> Cc: "[email protected]" <[email protected]>
>>>> Subject: Re: [MonoTouch] Anyone have a hint on HttpWebRequest and 64K
>>>>limit?
>>>>
>>>> Have you checked the MaxReceivedMessageSize setting on your WCF
>>>>binding?
>>>> What versions of IIS and .NET are you running on the server?
>>>>
>>>> On Thu, Jul 7, 2011 at 9:03 AM, Mark Handzlik
>>>><[email protected]>
>>>> wrote:
>>>>>
>>>>> Have an issue with send requests from Ipads that work fine when we
>>>>>send
>>>>> under 64K size. When request goes over 64K we receive Error 400 from
>>>>>server.
>>>>> Tried all types of settings on server in web.config section
>>>>> maxRequestLength="2097151"
>>>>> requestLengthDiskThreshold="400000"
>>>>> Registry settings for
>>>>> MaxRequestBytes and MaxFieldLength.
>>>>> Still Error 400
>>>>> Would really appreciate this as users can now have to be careful to
>>>>>sync
>>>>> data often and small to have operational apps.
>>>>> Below is the MT code section for client send:
>>>>> webRequest =
>>>>> (HttpWebRequest)WebRequest.Create(requestUri.ToString());
>>>>> if (this._credentials != null)
>>>>> {
>>>>> webRequest.Credentials = this._credentials;
>>>>> }
>>>>> // Set the method type
>>>>> webRequest.Method = "POST";
>>>>> webRequest.Accept = "application/atom+xml";
>>>>> webRequest.ContentType = "application/atom+xml";
>>>>> webRequest.Timeout = 1200000;
>>>>> switch (request.RequestType)
>>>>> {
>>>>> case CacheRequestType.UploadChanges:
>>>>> return ProcessUploadRequest(webRequest, request);
>>>>> case CacheRequestType.DownloadChanges:
>>>>> default:
>>>>> return ProcessDownloadRequest(webRequest,
>>>>>request);
>>>>> }
>>>>> }
>>>>> private object ProcessUploadRequest(HttpWebRequest
>>>>>webRequest,
>>>>> CacheRequest request)
>>>>> {
>>>>> using (Stream memoryStream = new MemoryStream())
>>>>> {
>>>>> // Create a SyncWriter to write the contents
>>>>> this._syncWriter = new ODataAtomWriter(base.BaseUri);
>>>>> this._syncWriter.StartFeed(true,
>>>>>request.KnowledgeBlob
>>>>>??
>>>>> new byte[0]);
>>>>> foreach (IOfflineEntity entity in request.Changes)
>>>>> {
>>>>> // Skip tombstones that dont have a ID element.
>>>>> if (entity.ServiceMetadata.IsTombstone &&
>>>>> string.IsNullOrEmpty(entity.ServiceMetadata.Id))
>>>>> {
>>>>> continue;
>>>>> }
>>>>> string tempId = null;
>>>>> // Check to see if this is an insert. i.e
>>>>> ServiceMetadata.Id is null or empty
>>>>> if
>>>>>(string.IsNullOrEmpty(entity.ServiceMetadata.Id))
>>>>> {
>>>>> if (TempIdToEntityMapping == null)
>>>>> {
>>>>> TempIdToEntityMapping = new
>>>>>Dictionary<string,
>>>>> IOfflineEntity>();
>>>>> }
>>>>> tempId = Guid.NewGuid().ToString();
>>>>> TempIdToEntityMapping.Add(tempId, entity);
>>>>> }
>>>>> this._syncWriter.AddItem(entity, tempId);
>>>>> }
>>>>>
>>>>> this._syncWriter.WriteFeed(XmlWriter.Create(memoryStream));
>>>>> memoryStream.Flush();
>>>>> // Set the content length
>>>>> webRequest.ContentLength = memoryStream.Position;
>>>>> using (Stream requestStream =
>>>>> webRequest.GetRequestStream())
>>>>> {
>>>>> CopyStreamContent(memoryStream, requestStream);
>>>>> // Close the request stream
>>>>> requestStream.Flush();
>>>>> requestStream.Close();
>>>>> }
>>>>> }
>>>>> // Fire the Before request handler
>>>>> this.FirePreRequestHandler(webRequest);
>>>>> // Get the response
>>>>>
>>>>> HttpWebResponse webResponse =
>>>>> (HttpWebResponse)webRequest.GetResponse();
>>>>> ________________________________
>>>>> The information contained in or attached to this electronic
>>>>>transmission
>>>>> constitutes confidential information and may be privileged and exempt
>>>>>from
>>>>> disclosure under applicable law. If you are not the intended
>>>>>recipient, you
>>>>> are on notice that any unauthorized disclosure, copying, distribution
>>>>>or
>>>>> dissemination of this information is strictly prohibited.
>>>>>
>>>>> _______________________________________________
>>>>> MonoTouch mailing list
>>>>> [email protected]
>>>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>>>
>>>>
>>>>
>>>> ________________________________
>>>> The information contained in or attached to this electronic
>>>>transmission
>>>> constitutes confidential information and may be privileged and exempt
>>>>from
>>>> disclosure under applicable law. If you are not the intended
>>>>recipient,
>>>>you
>>>> are on notice that any unauthorized disclosure, copying, distribution
>>>>or
>>>> dissemination of this information is strictly prohibited.
>>>>
>>>> _______________________________________________
>>>> MonoTouch mailing list
>>>> [email protected]
>>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>>
>>>>
>>
>>
>> The information contained in or attached to this electronic
>>transmission constitutes confidential information and may be privileged
>>and exempt from disclosure under applicable law. If you are not the
>>intended recipient, you are on notice that any unauthorized disclosure,
>>copying, distribution or dissemination of this information is strictly
>>prohibited.
>>
>_______________________________________________
>MonoTouch mailing list
>[email protected]
>http://lists.ximian.com/mailman/listinfo/monotouch
The information contained in or attached to this electronic transmission
constitutes confidential information and may be privileged and exempt from
disclosure under applicable law. If you are not the intended recipient, you
are on notice that any unauthorized disclosure, copying, distribution or
dissemination of this information is strictly prohibited.
_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch
